Database Reference
In-Depth Information
The new
referredBy
relationship
is represented as a reference to the user who did
the referring, while the
IS_FRIEND_OF
relationship between users maps nicely to
thesetoffriends.Theonlytrickypartseemstobethemodelingsurroundingthe
Viewing
class, which is trying to represent the scenario where a user has seen a movie and option-
ally rated it. Further inspection, however, reveals that this also fits perfectly into the Neo4j
relationship concept. The
Viewing
class represents the
HAS_SEEN
relationship with its
optional
stars
property, as well as the
User
who viewed the movie and the
Movie
ref-
erence itself.
So far so good; now it's time to do the mapping with SDN.
Note
It won't always be possible to find a logical POJO model that's so closely tied to the phys-
icalNeo4jstructure.Inthiscase,youwerequitefortunate,butinothercasesyoumayhave
to adapt your model to fit. In any case, what this does highlight is how general POJO mod-
eling concepts translate relatively well into Neo4j structures.
SDN modeling challenges
The logical model we've used for this chapter happens to translate very easily, and without
much adjusting, to the physical Neo4j storage structure. It's worth highlighting two scen-
arios where youmay have an object model that requires a bit ofadjusting to fit some ofthe
SDN mapping requirements. These are some common scenarios:
•
Using non-Set-based collections
—When modeling node entity relationships (via
lections may be used. For example, you can't have the following:
@RelatedTo
private Map<RelationshipType,Set<User>> users;
•
Entity equality
—SDN requires the database ID (the node/relationship ID) form
part of an object's identity. Quoting from the reference guide, “Entity equality can
beagreyarea,andit'sdebatablewhethernaturalkeysordatabaseidsbestdescribe
equality, there is the issue of versioning over time, etc. For Spring Data Neo4j we
haveadoptedtheconventionthatdatabase-issuedidsarethebasisforequality,and
