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

documentation updates

Browse Source
This commit is contained in:
Michael Hunger
2011-06-13 01:01:29 +02:00
parent 8c69ba436b
commit d179725f82
7 changed files with 147 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -1,6 +1,6 @@
<?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>
<section id="reference:aspectj">
<title>AspectJ support</title>
<para>
Behind the scenes, Spring Data Graph leverages <ulink url="http://www.eclipse.org/aspectj/">AspectJ</ulink>
@@ -34,11 +34,19 @@
include: introduction of methods to interfaces, declaration of additional interfaces for annotated
classes, and generified introduced methods.
</para>
<para>
IDE's not providing the full AJ support might mark parts of your code as errors.
You should rely on your build-system and test to verify the correctness of the code. You might also have
your Entities (or their interfaces) implement the <code>NodeBacked</code> and <code>RelationshipBacked</code>
interfaces directly to benefit from completion support and error checking.
</para>
<para>
Eclipse and STS support AspectJ via the AJDT plugin which can be installed from the update-site:
<ulink url="http://download.eclipse.org/tools/ajdt/36/update/">http://download.eclipse.org/tools/ajdt/36/update/</ulink>
(or for the latest development snapshot of the plugin
(it might be necessary to use the latest development snapshot of the plugin
<ulink url="http://download.eclipse.org/tools/ajdt/36/dev/update">http://download.eclipse.org/tools/ajdt/36/dev/update</ulink>).
The current version that does not show incorrect errors is AspectJ 1.6.12.M1 (included in STS 2.7.0.M2), previous versions are reported
to mislead the user.
</para>
<para>
The AspectJ support in IntelliJ IDEA lacks some of the features. JetBrains is working on improving

8
src/docbkx/reference/programming-model/attachdetach.xml
View File

@@ -81,6 +81,14 @@ movie.setTopActor(actor);
this behavior is not dependent on any configured relationship direction on the annotations.
It is a matter of Java references and is not related to the data model in the database.
</para>
<para>
The persist operation (merge) stores all properties of the entity to the graph database
and puts the entity in attached mode. There is no need to update the reference to the Java
POJO as the underlying backing node handles the read-through transparently. If multiple
object instances that point to the same node are persisted, the ordering is not important
as long as they contain distinct changes. For concurrent changes a concurrent modification
exception is thrown (subject to be parametrizable in the future).
</para>
<para>
If the relationships form a cycle, then the entities will first all be assigned a node in
the database, and then the relationships will be created. The cascading of <code>persist()</code>

32
src/docbkx/reference/programming-model/node-entities.xml
View File

@@ -15,6 +15,10 @@
<code>useShortNames</code> attribute overridden to false, the property and relationship names will
have the class name of the entity prepended.
</para>
<para>
<code>@NodeEntity</code> annotations are inherited from super-types and interfaces. It is not necessary
to annotate your domain objects at every inheritance level.
</para>
<para>
If the <code>partial</code> attribute is set to true, this entity takes part in a cross-store setting,
where the entity lives in both the graph database and a JPA data source. See
@@ -44,6 +48,10 @@ public class Movie {
custom conversion factory that comes with converters for <code>Enum</code>s and <code>Date</code>s.
Transient fields are not persisted.
</para>
<para>
Currently there is no support for handling arbitrary collections of primitive or convertable values.
Support for this will be added by the 1.1. release.
</para>
<para>
This annotation is typically used with cross-store persistence. When a node entity is configured
as partial, then all fields that should be persisted to the graph must be explicitly annotated
@@ -63,6 +71,30 @@ public class Movie {
</para>
</section>
<section>
<title>@GraphQuery: fields as query result views</title>
<para>
The <code>@GraphQuery</code> annotation leverages the delegation infrastructure used by the
Spring Data Graph aspects. It provides dynamic fields which, when accessed, return the values
selected by the provided query language expression. The provided query must contain a placeholder
for the id of the current entity <code>start n=(%d) match n-[:FRIEND]->friend return friend</code>
As graph queries can return variable number of entities the annotation can be put onto fields
with a single value, an Iterable of a type or an Iterable of <code>Map&lt;String,Object&gt;</code>.
The class of the resulting node entities must right now provided with the <code>elementClass</code> attribute.
Additional parameters are added to the query with Java's String.format substitution.
</para>
<example>
<title>@GraphQuery from a node entity</title>
<programlisting language="java"><![CDATA[@NodeEntity
public class Group {
@GraphQuery(value = "start n=(%d) match (n)-[:%s]->(friend) return friend",
elementClass = Person.class, params = "FRIEND")
private Iterable<Person> friends;
}
]]></programlisting>
</example>
</section>
<section>
<title>@GraphTraversal: fields as traversal result views</title>
<para>

21
src/docbkx/reference/programming-model/relationships.xml
View File

@@ -9,6 +9,11 @@
Spring Data Graph has special support to represent Neo4j relationships as entities too, but it is often
not needed.
</para>
<note>
<para>
As of Neo4j 1.4.M03, circular references are allowed. Spring Data Graph reflects this accordingly.
</para>
</note>
<section id="reference:programming_model:relationships:relatedto">
<title>@RelatedTo: Connecting node entities</title>
<para>
@@ -69,7 +74,12 @@ public class Actor {
</para>
</note>
<para>
By setting direction to BOTH, relationships are created in the outgoing direction, but when the
When you use an Interface as target type for the <code>Set</code> and/or as <code>elementClass</code>
please make sure that it implements <code>NodeBacked</code> either by extending that Super-Interface manually
or by annotating the Interface with <code>@NodeEntity</code> too.
</para>
<para>
By setting direction to <code>BOTH</code>, relationships are created in the outgoing direction, but when the
1:N field is read, it will include relationships in both directions. A cardinality of M:N is
not necessary because relationships can be navigated in both directions.
</para>
@@ -79,8 +89,15 @@ public class Actor {
<code>entity.relateTo(target, type)</code> available on each NodeEntity.
These methods find and create Neo4j relationships. It is also possible to manually remove
relationships by using <code>entity.removeRelationshipTo(target, type)</code>.
Using these methods is rarely necessary though.
Using these methods is significantly faster than adding/removing from the collection of
relationships as it doesn't have to re-synchronize a whole set of relationships with the graph.
</para>
<note>
<para>
Other collection types than <code>Set</code> are not supported so far, also currently NO
<code>Map&lt;RelationshipType,Set&lt;NodeBacked&gt;&gt;</code>.
</para>
</note>
</section>
<section>