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

Added docs for typerepresentationstrategies. Added tests for noop strategies.

Browse Source
This commit is contained in:
David Montag
2011-03-30 22:51:09 -07:00
parent 632afae487
commit 098a61646e
12 changed files with 293 additions and 226 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
src/docbkx/reference/programming-model/finders.xml
View File

@@ -2,6 +2,7 @@
<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
<section>
<title>Finding nodes with finders</title>
<note>TODO: rewrite to repositories</note>
<para>Spring Data Graph also comes with a typed, repository-like Finder implementation that provides methods for
locating nodes and relationships. Those methods return instances of the node and relationship entities,
not the graph primitives from Neo4j. Finders delegate to the configured <code>NodeTypeStrategy</code> for type
@@ -68,15 +69,8 @@ Iterable<Person> davesFriends = graphRepository.findAllByTraversal(dave,
Internally the mapping from java types to the graph is handled by a <code>NodeTypeStrategy</code> instance
that is configured with the <code>GraphDatabaseContext</code>. The strategy is called on entity creation and
removal and provides methods for retrieving entities based on type. It also comes with methods confirming or
retrieving java types from the actual graph node. (see also <xref linkend="nodetypestrategy"/>)
</para>
<para>
The default strategy (<code>IndexingNodeTypeStrategy</code>)
uses indexing (index "__types__") and node properties ("__type__") to store the type information in the graph.
The second strategy uses an in graph structure to represent the inheritance hierarchy links the actual node
entity nodes to their concrete class nodes. Instance counts are updated on each of the class nodes in the hierarchy.
The last provided strategy is a No-Op strategy that doesn't care about type information.
retrieving java types from the actual graph node. (see also
<xref linkend="reference:programming-model:typerepresentationstrategy"/>)
</para>
</section>
</section>

48
src/docbkx/reference/programming-model/nodetypestrategy.xml
View File

@@ -1,48 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
<section id="nodetypestrategy">
<title>Storing Type Information in the Graph</title>
<para>
There are several ways to represent the Java type hierarchy of the data model in the graph. In general for all
node and relationship entities type information is needed to perform certain repository operations. Some of
this type information is saved in the graph database.
</para>
<para>
Implementations of <code>NodeTypeStrategy</code> take care of persisting this information on entity instance
creation. They also provide the repository methods that use this type information to perform their operations
like findAll, count, etc.
</para>
<para>
There are three available implementations to choose from.
<itemizedlist>
<listitem>
<para><code>IndexingNodeTypeStrategy</code></para>
<para>
Stores entity types in the integrated index. Each entity node gets indexed with its type and
any supertypes that are also <code>@NodeEntity</code>-annotated. The special index used for this
is called <code>__types__</code>. Additionally, in order to get the type of an entity node, each
node has a property <code>__type__</code> with the type of that entity.
</para>
</listitem>
<listitem>
<para><code>SubReferenceNodeTypeStrategy</code></para>
<para>
Stores entity types in a tree in the graph representing the type hierarchy. Each entity
has a INSTANCE_OF relationship to a type node representing that entity's type. The type may or
may not have a SUBCLASS_OF relationship to another type node.
</para>
</listitem>
<listitem>
<para><code>NoopNodeTypeStrategy</code></para>
<para>
Does not store any type information, and does hence not support finding by type, counting by type,
or retrieving the type of any entity.
</para>
</listitem>
</itemizedlist>
</para>
<para>
The default implementation is <code>IndexingNodeTypeStrategy</code> for new graphs. If using an existing
graph, Spring Data Graph will default to the strategy first used when the graph was created.
</para>
</section>

2
src/docbkx/reference/programming-model/programming-model.xml
View File

@@ -14,7 +14,7 @@
<xi:include href="finders.xml"/>
<xi:include href="transactions.xml"/>
<xi:include href="attachdetach.xml"/>
<xi:include href="nodetypestrategy.xml"/>
<xi:include href="typerepresentationstrategy.xml"/>
<xi:include href="introducedmethods.xml"/>
<xi:include href="projection.xml"/>
<xi:include href="beanvalidation.xml"/>

78
src/docbkx/reference/programming-model/typerepresentationstrategy.xml Normal file
View File

@@ -0,0 +1,78 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
<section id="reference:programming-model:typerepresentationstrategy">
<title>Storing type information in the graph</title>
<para>
There are several ways to represent the Java type hierarchy of the data model in the graph. In general, for all
node and relationship entities, type information is needed to perform certain repository operations. Some of
this type information is saved in the graph database.
</para>
<para>
Implementations of
<code>TypeRepresentationStrategy</code>
take care of persisting this information on entity instance
creation. They also provide the repository methods that use this type information to perform their operations,
like findAll and count.
</para>
<para>
There are three available implementations for node entities to choose from.
<itemizedlist>
<listitem>
<para>
<code>IndexingNodeTypeRepresentationStrategy</code>
</para>
<para>
Stores entity types in the integrated index. Each entity node gets indexed with its type and
any supertypes that are also<code>@NodeEntity</code>-annotated. The special index used for this
is called<code>__types__</code>. Additionally, in order to get the type of an entity node, each
node has a property
<code>__type__</code>
with the type of that entity.
</para>
</listitem>
<listitem>
<para>
<code>SubReferenceNodeTypeRepresentationStrategy</code>
</para>
<para>
Stores entity types in a tree in the graph representing the type hierarchy. Each entity
has a INSTANCE_OF relationship to a type node representing that entity's type. The type may or
may not have a SUBCLASS_OF relationship to another type node.
</para>
</listitem>
<listitem>
<para>
<code>NoopNodeTypeRepresentationStrategy</code>
</para>
<para>
Does not store any type information, and does hence not support finding by type, counting by type,
or retrieving the type of any entity.
</para>
</listitem>
</itemizedlist>
</para>
<para>
There are two implementations for relationship entities available, same behavior as the corresponding ones
above:
<itemizedlist>
<listitem>
<para>
<code>IndexingRelationshipTypeRepresentationStrategy</code>
</para>
</listitem>
<listitem>
<para>
<code>NoopRelationshipTypeRepresentationStrategy</code>
</para>
</listitem>
</itemizedlist>
</para>
<para>
Spring Data Graph will by default autodetect which are the most suitable strategies for node and relationship
entities. For new data stores, it will always opt for the indexing strategies. If a data store was created
with the older<code>SubReferenceNodeTypeRepresentationStrategy</code>, then it will continue to use that
strategy for node entities. It will however in that case use the no-op strategy for relationship entities,
which means that the old data stores have no support for searching for relationship entities. The indexing
strategies are recommended for all new users.
</para>
</section>