renaming spring data graph to spring data neo4j
This commit is contained in:
Michael Hunger
@@ -3,11 +3,11 @@
|
||||
<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>
|
||||
Behind the scenes, Spring Data Neo4j leverages <ulink url="http://www.eclipse.org/aspectj/">AspectJ</ulink>
|
||||
aspects to modify the behavior of simple annotated POJO entities
|
||||
(see <xref linkend="reference:aspectj-details"/>). Each node entity is backed by a graph node that holds its
|
||||
properties and relationships to other entities. AspectJ is used for intercepting field access, so that
|
||||
Spring Data Graph can retrieve the information from the entity's backing node or relationship in the database.
|
||||
Spring Data Neo4j can retrieve the information from the entity's backing node or relationship in the database.
|
||||
</para>
|
||||
<para>
|
||||
The aspect introduces some internal fields and some public methods
|
||||
@@ -17,7 +17,7 @@
|
||||
Introduced methods for <code>equals()</code> and <code>hashCode()</code> use the underlying node or relationship.
|
||||
</para>
|
||||
<para>
|
||||
Spring Data Graph internally uses an abstraction called <code>EntityState</code> that the field
|
||||
Spring Data Neo4j internally uses an abstraction called <code>EntityState</code> that the field
|
||||
access and instantiation advices of the aspect delegate to. This way, the aspect code is kept to a
|
||||
minimum, focusing mainly on the pointcuts and delegation code. The <code>EntityState</code> then uses
|
||||
a number of <code>FieldAccessorFactories</code> to create a <code>FieldAccessor</code> instance per
|
||||
@@ -27,7 +27,7 @@
|
||||
<section>
|
||||
<title>AspectJ IDE support</title>
|
||||
<para>
|
||||
As Spring Data Graph uses some advanced features of AspectJ, users may experience issues with
|
||||
As Spring Data Neo4j uses some advanced features of AspectJ, users may experience issues with
|
||||
their IDE reporting errors where in fact there are none. Features that might be reported wrongfully
|
||||
include: introduction of methods to interfaces, declaration of additional interfaces for annotated
|
||||
classes, and generified introduced methods.
|
||||
|
||||
@@ -69,7 +69,7 @@ movie.setTopActor(actor);
|
||||
</para>
|
||||
<para>
|
||||
Neither the actor nor the movie has been assigned a node in the graph. If we were to call
|
||||
<code>movie.persist()</code>, then Spring Data Graph would first create a node for the movie.
|
||||
<code>movie.persist()</code>, then Spring Data Neo4j would first create a node for the movie.
|
||||
It would then note that there is a relationship to an actor, so it would call actor.persist()
|
||||
in a cascading fashion. Once the actor has been persisted, it will create the relationship
|
||||
from the movie to the actor. All of this will be done atomically in one transaction.
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
<section id="reference:programming-model:validation">
|
||||
<title>Bean validation (JSR-303)</title>
|
||||
<para>
|
||||
Spring Data Graph supports property-based validation support. When a property is changed, it is
|
||||
Spring Data Neo4j supports property-based validation support. When a property is changed, it is
|
||||
checked against the annotated constraints, e.g. <code>@Min</code>, <code>@Max</code>,
|
||||
<code>@Size</code>, etc. Validation errors throw a <code>ValidationException</code>. The validation
|
||||
support that comes with Spring is used for evaluating the constraints. To use this feature, a validator
|
||||
|
||||
@@ -13,7 +13,7 @@
|
||||
<title>Exact and numeric index</title>
|
||||
<para>
|
||||
When using the standard Neo4j API, nodes and relationships have to be manually indexed with
|
||||
key-value pairs, typically being the property name and value. When using Spring Data Graph,
|
||||
key-value pairs, typically being the property name and value. When using Spring Data Neo4j,
|
||||
this task is simplified to just adding an <code>@Indexed</code> annotation on entity fields
|
||||
by which the entity should be searchable. This will result in automatic updates of the index
|
||||
every time an indexed field changes.
|
||||
@@ -62,7 +62,7 @@ for (Person middleAgedDeveloper : graphRepository.findAllByRange("age", 20, 40))
|
||||
<section>
|
||||
<title>Fulltext indexes</title>
|
||||
<para>
|
||||
Spring Data Graph also supports fulltext indexes. By default, indexed fields are stored in
|
||||
Spring Data Neo4j also supports fulltext indexes. By default, indexed fields are stored in
|
||||
an exact lookup index. To have them analyzed and prepared for fulltext search, the
|
||||
<code>@Indexed</code> annotation has the boolean <code>fulltext</code> attribute.
|
||||
|
||||
|
||||
@@ -44,7 +44,7 @@ public class Movie {
|
||||
<para>
|
||||
It is not necessary to annotate data fields, as they are persisted by default; all fields that
|
||||
contain primitive values are persisted directly to the graph. All fields convertible to String
|
||||
using the Spring conversion services will be stored as a string. Spring Data Graph includes a
|
||||
using the Spring conversion services will be stored as a string. Spring Data Neo4j includes a
|
||||
custom conversion factory that comes with converters for <code>Enum</code>s and <code>Date</code>s.
|
||||
Transient fields are not persisted.
|
||||
</para>
|
||||
@@ -75,7 +75,7 @@ public class Movie {
|
||||
<title>@Query: fields as query result views</title>
|
||||
<para>
|
||||
The <code>@Query</code> annotation leverages the delegation infrastructure used by the
|
||||
Spring Data Graph aspects. It provides dynamic fields which, when accessed, return the values
|
||||
Spring Data Neo4j 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 named <code>%start</code>
|
||||
for the id of the current entity. For instance <code>start n=(%start) match n-[:FRIEND]->friend return friend</code>.
|
||||
Graph queries can return variable number of entities. That's why annotation can be put onto fields
|
||||
@@ -104,7 +104,7 @@ public class Group {
|
||||
<title>@GraphTraversal: fields as traversal result views</title>
|
||||
<para>
|
||||
The <code>@GraphTraversal</code> annotation leverages the delegation infrastructure used by the
|
||||
Spring Data Graph aspects. It provides dynamic fields which, when accessed, return an Iterable
|
||||
Spring Data Neo4j aspects. It provides dynamic fields which, when accessed, return an Iterable
|
||||
of node entities that are the result of a traversal starting at the entity containing the field.
|
||||
The <code>TraversalDescription</code> used for this is created by the
|
||||
<code>FieldTraversalDescriptionBuilder</code> class defined by the <code>traversalBuilder</code>
|
||||
|
||||
@@ -3,10 +3,10 @@
|
||||
<chapter id="programming-model" xmlns:xi="http://www.w3.org/2001/XInclude">
|
||||
<title>Programming model</title>
|
||||
<para>
|
||||
This chapter covers the fundamentals of the programming model behind Spring Data Graph. It discusses the
|
||||
AspectJ features used and the annotations provided by Spring Data Graph and how to use them.
|
||||
This chapter covers the fundamentals of the programming model behind Spring Data Neo4j. It discusses the
|
||||
AspectJ features used and the annotations provided by Spring Data Neo4j and how to use them.
|
||||
Examples for this section are taken from the "IMDB" project of
|
||||
<ulink url="http://github.com/SpringSource/spring-data-graph-examples">Spring Data Graph examples</ulink>.
|
||||
<ulink url="http://github.com/SpringSource/spring-data-neo4j-examples">Spring Data Neo4j examples</ulink>.
|
||||
</para>
|
||||
<xi:include href="aspectj.xml"/>
|
||||
<xi:include href="node-entities.xml"/>
|
||||
|
||||
@@ -15,7 +15,7 @@
|
||||
(not related in the inheritance hierarchy or even an interface) order type that is valid in the current
|
||||
context and only offers the attributes and methods needed here would be very benefitial.
|
||||
</para>
|
||||
<para>Spring Data Graph offers initial support for projecting node and relationship entities to different target
|
||||
<para>Spring Data Neo4j offers initial support for projecting node and relationship entities to different target
|
||||
types. All instances of this projected entity share the same backing node or relationship, so data changes are
|
||||
reflected immediately.
|
||||
</para>
|
||||
|
||||
@@ -6,19 +6,19 @@
|
||||
Since relationships are first-class citizens in Neo4j, associations between node entities are represented
|
||||
by relationships. In general, relationships are categorized by a type, and start and end nodes (which
|
||||
imply the direction of the relationship). Relationships can have an arbitrary number of properties.
|
||||
Spring Data Graph has special support to represent Neo4j relationships as entities too, but it is often
|
||||
Spring Data Neo4j 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.
|
||||
As of Neo4j 1.4.M03, circular references are allowed. Spring Data Neo4j reflects this accordingly.
|
||||
</para>
|
||||
</note>
|
||||
<section id="reference:programming_model:relationships:relatedto">
|
||||
<title>@RelatedTo: Connecting node entities</title>
|
||||
<para>
|
||||
Every field of a node entity that references one or more other node entities is backed by relationships
|
||||
in the graph. These relationships are managed by Spring Data Graph automatically.
|
||||
in the graph. These relationships are managed by Spring Data Neo4j automatically.
|
||||
</para>
|
||||
<para>
|
||||
The simplest kind of relationship is a single field pointing to another node entity (1:1).
|
||||
@@ -56,15 +56,15 @@ public class Actor {
|
||||
</example>
|
||||
<para>
|
||||
Fields referencing other entities should not be manually initialized, as they are managed by
|
||||
Spring Data Graph under the hood. 1:N fields can be accessed immediately, and Spring Data Graph
|
||||
Spring Data Neo4j under the hood. 1:N fields can be accessed immediately, and Spring Data Neo4j
|
||||
will provide a java.util.Set representing the relationships. If the returned set is modified,
|
||||
the changes are reflected in the graph. Spring Data Graph also ensures that there is only one
|
||||
the changes are reflected in the graph. Spring Data Neo4j also ensures that there is only one
|
||||
relationship of a given type between any two given entities.
|
||||
</para>
|
||||
<note>
|
||||
<para>
|
||||
Before an entity has been attached with <code>persist()</code> for the first time, it will
|
||||
not have its state managed by Spring Data Graph. For example, given the Actor class defined above,
|
||||
not have its state managed by Spring Data Neo4j. For example, given the Actor class defined above,
|
||||
if <code>actor.movies</code> was accessed in a non-persisted entity, it would return
|
||||
<code>null</code>, whereas if it was accessed in a persisted entity, it would return
|
||||
an empty managed set.
|
||||
|
||||
@@ -3,14 +3,14 @@
|
||||
<section id="reference:programming-model:repositories">
|
||||
<title>CRUD with repositories</title>
|
||||
<para>
|
||||
The repositories provided by Spring Data Graph build on the composable repository infrastructure
|
||||
The repositories provided by Spring Data Neo4j build on the composable repository infrastructure
|
||||
in <ulink url="http://static.springsource.org/spring-data/data-jpa/docs/current/reference/html/#repositories.custom-implementations">Spring Data Commons</ulink>.
|
||||
They allow for interface based composition of repositories consisting of provided default
|
||||
implementations for certain interfaces and additional custom implementations for other methods.
|
||||
</para>
|
||||
<!--<note>-->
|
||||
<!--<para>-->
|
||||
<!--Spring Data Graph provides only the infrastructure and some default repository implementations-->
|
||||
<!--Spring Data Neo4j provides only the infrastructure and some default repository implementations-->
|
||||
<!--so far. Future releases will support finders derived from method names, named queries, and-->
|
||||
<!--annotated query methods.-->
|
||||
<!--(e.g.-->
|
||||
@@ -20,11 +20,11 @@
|
||||
<!--</para>-->
|
||||
<!--</note>-->
|
||||
<para>
|
||||
Spring Data Graph repositories support annotated and named queries for the Neo4j
|
||||
Spring Data Neo4j repositories support annotated and named queries for the Neo4j
|
||||
<ulink url="http://docs.neo4j.org/chunked/milestone/query-lang.html">Cypher</ulink> query-language.
|
||||
</para>
|
||||
<para>
|
||||
Spring Data Graph comes with typed repository implementations that provide methods for
|
||||
Spring Data Neo4j comes with typed repository implementations that provide methods for
|
||||
locating node and relationship entities. There are 3 types of basic repository interfaces
|
||||
and implementations. <code>CRUDRepository</code> provides basic operations,
|
||||
<code>IndexRepository</code> and <code>NamedIndexRepository</code> delegate to Neo4j's internal
|
||||
@@ -147,8 +147,8 @@
|
||||
|
||||
<section>
|
||||
<title>Named Queries</title>
|
||||
<para>Spring Data Graph also supports the notion of named queries which are externalized in property-config-files
|
||||
(<code>META-INF/graph-named-queries.properties</code>). Those files have the format:
|
||||
<para>Spring Data Neo4j also supports the notion of named queries which are externalized in property-config-files
|
||||
(<code>META-INF/neo4j-named-queries.properties</code>). Those files have the format:
|
||||
<code>Entity.finderName=query</code> (e.g. <code>Person.findBoss=start p=(%person) match (p)<-[:BOSS]-(boss) return boss</code>).
|
||||
Otherwise named queries support the same parameters as annotated queries. For using the named parameters you have to either
|
||||
annotate the parameters of the method with the <code>@Param("person")</code> annotation or enable debug symbols.
|
||||
@@ -256,7 +256,7 @@ public class PersonRepositoryImpl implements PersonRepositoryExtension {
|
||||
|
||||
// configure the repositories, preferably via the datagraph:repositories namespace
|
||||
// (graphDatabaseContext reference is optional)
|
||||
<datagraph:repositories base-package="org.springframework.data.neo4j"
|
||||
<neo4j:repositories base-package="org.springframework.data.neo4j"
|
||||
graph-database-context-ref="graphDatabaseContext"/>
|
||||
|
||||
// have it injected
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
boundaries. Reading data does however not require transactions.
|
||||
</para>
|
||||
<para>
|
||||
Spring Data Graph integrates with transaction managers configured using Spring. The simplest
|
||||
Spring Data Neo4j integrates with transaction managers configured using Spring. The simplest
|
||||
scenario of just running the graph database uses a SpringTransactionManager provided by the
|
||||
Neo4j kernel to be used with Spring's JtaTransactionManager. That is, configuring Spring to
|
||||
use Neo4j's transaction manager.
|
||||
@@ -16,7 +16,7 @@
|
||||
<para>
|
||||
The explicit XML configuration given below is encoded in the <code>Neo4jConfiguration</code>
|
||||
configuration bean that uses Spring's <code>@Configuration</code> feature. This greatly
|
||||
simplifies the configuration of Spring Data Graph.
|
||||
simplifies the configuration of Spring Data Neo4j.
|
||||
<!--An example is shown further below.-->
|
||||
</para>
|
||||
</note>
|
||||
@@ -70,7 +70,7 @@
|
||||
<para>
|
||||
One can also configure a stock XA transaction manager (e.g. Atomikos, JOTM, App-Server-TM) to be
|
||||
used with Neo4j and the other resources. For a bit less secure but fast 1 phase commit best effort,
|
||||
use <code>ChainedTransactionManager</code>, which comes bundled with Spring Data Graph. It takes a
|
||||
use <code>ChainedTransactionManager</code>, which comes bundled with Spring Data Neo4j. It takes a
|
||||
list of transaction managers as constructor params and will handle them in order for transaction
|
||||
start and commit (or rollback) in the reverse order.
|
||||
</para>
|
||||
|
||||
@@ -66,7 +66,7 @@
|
||||
</itemizedlist>
|
||||
</para>
|
||||
<para>
|
||||
Spring Data Graph will by default autodetect which are the most suitable strategies for node and relationship
|
||||
Spring Data Neo4j 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,
|
||||
|
||||
Reference in New Issue
Block a user