Databases Reference
In-Depth Information
Figure 3-11. A naive, lossy approach fails to appreciate that forwarded and replied-to
emails are first-class entities
However, this approach quickly proves inadequate. Adding
FORWARDED
or
REPLIED
re‐
lationships is naive and lossy in much the same way as our original use of an
EMAILED
relationship. To illustrate this, consider the following
CREATE
statements:
START
email =
node
:emails(
id
=
'1234'
);
CREATE
(alice)-[:REPLIED_TO]->(email);
CREATE
(davina)-[:FORWARDED]->(email)-[:TO]->(charlie);
In the first
CREATE
statement we're trying to record the fact that Alice replied to a par‐
ticular email. The statement makes logical sense when read from left to right, but the
sentiment is lossy—we can't tell whether Alice replied to all the recipients of
email
or
directly to the author. All we know is that some reply was sent. The second statement
also reads well from left to right: Davina forwarded
email
to Charlie. But we already
use the
TO
relationship to indicate that a given email has a
TO
header identifying the
primary recipients. Reusing
TO
here makes it impossible to tell who was a recipient and
who received a forwarded version of an email.
To resolve this problem, we have to consider the fundamentals of the domain. A reply
to an email is itself a new email, albeit with some relationship to a previous message.
Whether the reply is to the original sender, all recipients, or a subset can be easily mod‐
eled using the same familiar
TO
,
CC
, and
BCC
relationships, while the original email itself
can be referenced via a
REPLY_TO
relationship. Here's a revised series of writes resulting
from several email actions (again, we've omitted the necessary
START
clauses):
CREATE
(email_6 {
id
:
'6'
, content:
'email'
}),
(bob)-[:SENT]->(email_6),
(email_6)-[:TO]->(charlie),
(email_6)-[:TO]->(davina);
