Spring/spring-data-neo4j
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

revised some language to clarify meaning about mapping modes

Browse Source
This commit is contained in:
Andreas Kollegger
2011-12-12 23:01:55 -05:00
parent c0df9c721b
commit 0689d08158
1 changed files with 8 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
src/docbkx/reference/programming-model/mapping.xml
View File

@@ -4,32 +4,32 @@
<title>Object Graph Mapping</title>
<para>
Up until recently Spring Data Neo4j supported only the more advanced and flexible AspectJ based mapping approach, see <xref linkend="reference:aspectj" />.
Feedback about issues with the AspectJ tooling and other implications supported us in adding a simpler mapping (see <xref linkend="reference:simple-mapping" />) to Spring Data Neo4j.
Both versions work with the same annotations and provide similar API's, but different behaviour.
Feedback about issues with the AspectJ tooling and other implications persuaded us to add a simpler mapping (see <xref linkend="reference:simple-mapping" />) to Spring Data Neo4j.
Both versions work with the same annotations and provide similar API's, but differ in behaviour.
</para>
<para>
Reflection and Annotation-based metadata is collected about persistent entities in the <code>Neo4jMappingContext</code>
which provides it to any part of the library. The information is stored in <code>Neo4jPersistentEntiy</code> instances
which hold all the <code>Neo4jPersistentProperty</code>'s of the type. Each entity can be queried if it represents
which provides it to any part of the library. The information is stored in <code>Neo4jPersistentEntity</code> instances
which hold all the <code>Neo4jPersistentProperty</code>'s of the type. Each entity can be checked to determine whether it represents
a Node or a Relationship. Properties declare detailed data about their indexing and relationship information as well
as type information that also covers nested generic types. With all that information available it is simple to
select the appropriate strategy for mapping each entity and field to elements, relationships and properties of the graph.
</para>
<para>
The main difference differs in the way of accessing the graph. In the simple mapping the required
The main difference is in the way of accessing the graph. In the simple mapping the required
information is copied into the entity on load and only stored back when an explicit save operation occurs. In the
advanced mapping (AspectJ) approach a node or relationship is attached via an additional field to the entity and
advanced mapping (AspectJ-enhanced) approach a node or relationship is attached via an additional field to the entity and
all read- and write-operations (inside of Transactions) happen through that.
</para>
<para>
For the simple mapping mode declaration of fetch strategies for related entities is necessary to avoid loading
For the simple mapping mode, declaration of fetch strategies for related entities is necessary to avoid loading
the whole graph eagerly into memory. The initial approach uses just a simple <code>@Fetch</code> annotations
on relationship properties. The resulting <code>MappingPolicy</code> is provided to the infrastructure methods to ensure
the correct loading behaviour. Both, <code>Neo4jPersistentEntiy</code> and <code>Neo4jPersistentProperty</code>
can be queried for the <code>MappingPolicy</code>.
</para>
<para>
Otherwise the two approaches are sharing lots of the infrastructure. E.g. for creating new entity instances from
Otherwise the two approaches share much of the infrastructure. E.g. for creating new entity instances from
type information store in the graph (<xref linkend="reference:programming-model:typerepresentationstrategy"/>),
the infrastructure for mapping individual fields to graph properties and relationships and everything related to
indexing and querying. A certain part of that is also exposed via the Neo4jTemplate for direct use.