Editorial changes

This commit is contained in:
Andres Taylor
2011-03-23 11:55:09 +01:00
parent 00d2ed8c04
commit 54e5ca16de
6 changed files with 26 additions and 23 deletions

View File

@@ -9,7 +9,7 @@
</para><para>
It's time to put this to a test. How can we be assured that a field is persisted to the graph store? There seemed to be two possibilities. First was to get a
GraphDatabaseContext injected and use its getById() method. The other one was a Finder approach. But let's try to keep things simple.
How can we persist an entity and how to get its id? No idea, so time to hit the documentation again, revealing that there are a bunch of methods introduced to the
How can we persist an entity and how to get its id? Looking at the documentation revealed that there are a bunch of methods introduced to the
entities by the aspects. That's not obvious, but we found the two that would help here - entity.persist() and entity.getNodeId().
</para><para>
So our test looked like this.

View File

@@ -3,7 +3,7 @@
<chapter id="tutorial_domain">
<title>Setting the Stage - Movies Domain</title>
<para>
The domain model was the next thing we planned to work on. We wanted to sketch it out first before diving into library details. We also looked at the datamodel of core themoviedb data to
The domain model was the next thing we planned to work on. We wanted to sketch it out first before diving into library details. We also looked at the datamodel of core themoviedb data to
confirm that it matched our expectations.
<!--
@@ -35,11 +35,13 @@ class Actor {
Set<Movie> filmography;
Role playedIn(Movie movie, String role);
}
class Role {
Movie movie;
Actor actor;
String role;
}
class User {
String login;
String name;
@@ -49,6 +51,7 @@ class User {
Rating rate(Movie movie, int stars, String comment);
void befriend(User user);
}
class Rating {
User user;
Movie movie;

View File

@@ -3,14 +3,14 @@
<chapter id="tutorial_neo4j">
<title>Graphs ahead - Learning Neo4j</title>
<para>
Then came the unknown - how to put these domain objects into the graph. First we read up about graph databases, especially <ulink url="http://neo4j.org">Neo4j</ulink>.
The Neo4j datamodel consists of nodes and relationships all of which can have properties. Relationships are first class citizens in Neo4j, meaning we can link together nodes into semantically rich networks - we really liked that.
Then we found we could <ulink url="http://wiki.neo4j.org/content/Index_Framework">index nodes and relationships</ulink> by {name, value} pairs to quickly get hold of them as starting points for further processing. We also found we could imperatively traverse of relationships using the core API, and in a declarative way using a query-like <ulink url="http://wiki.neo4j.org/content/Traversal_Framework">Traversal Description</ulink>.
Now came the unknown - how to put these domain objects into the graph. First we read up about graph databases, especially <ulink url="http://neo4j.org">Neo4j</ulink>.
The Neo4j datamodel consists of nodes and relationships, both of which can have properties. Relationships are first class citizens in Neo4j, meaning we can link together nodes into semantically rich networks - we really liked that.
Then we found we could <ulink url="http://docs.neo4j.org/chunked/snapshot/indexing.html">index nodes and relationships</ulink> by {name, value} pairs to quickly get hold of them as starting points for further processing. We also found we could imperatively traverse of relationships using the core API, and in a declarative way using a query-like <ulink url="http://wiki.neo4j.org/content/Traversal_Framework">Traversal Description</ulink>.
</para><para>
We also learned that Neo4j was fully transactional and completely upholds ACID guarantees for out data. This is unusual for NoSQL databases, but easier for us to get
my head around than non-transactional eventual consistency. It also makes us feel safe, though it also means that we had to manage transactions. Keep that in mind.
our head around than non-transactional eventual consistency. It also makes us feel safe, though it also means that we had to manage transactions. Keep that in mind.
</para><para>
Initially we used the core Neo4j API to get a feeling for that. And also to see, how (probably) the domain might look when it's saved in the graph store. After adding the maven
Initially we used the core Neo4j API to get a feeling for that. And also to see, how (probably) the domain might look when it's saved in the graph store. After adding the Maven
dependency, it was ready to go.
</para><para>
<programlisting language="xnk" ><![CDATA[

View File

@@ -7,7 +7,7 @@
account had to be secured as well.
</para><para>
We used Spring Security for that, writing a simple UserDetailsService that used a repository for looking up the users and validating their credentials. The config is located
in a separate applicationContext-security.xml. But first, as always, maven and web.xml setup.
in a separate applicationContext-security.xml. But first, as always, Maven and web.xml setup.
</para>
<para>
<example>

View File

@@ -7,19 +7,19 @@
that should be enough.
</para><para>
What database would fit both the complex network of cineasts, movies, actors, roles, ratings and friends? And also be able to support the
recommendation algorithms that I thought of? I had no idea.
recommendation algorithms that we had in mind? We had no idea.
</para><para>
But, wait, there is the new Spring Data project, started in 2010, which brings
the convenience of the Spring programming model to NoSQL databases. That should fit our experience and help us to get started. We looked
at the list of projects supporting the different NoSQL databases. Only one mentioned the kind of social network we were thinking of -
Spring Data Graph for Neo4j, a graph database. Neo4j's pitch of "value in relationships" and the accompanying docs looked like what we needed.
So we decided to give it a try.
We decided to give it a try.
</para>
<section>
<title>Preparations - Required Setup</title>
<para>
To setup the project we created a public github account and began setting up the infrastructure for a spring web project using maven as build
system. So we added the dependencies for the springframework libraries, put the web.xml for the DispatcherServlet and the applicationContext.xml
To setup the project we created a public github account and began setting up the infrastructure for a spring web project using Maven as build
system. So we added the dependencies for the Spring Framework libraries, put the web.xml for the DispatcherServlet and the applicationContext.xml
in the webapp directory.
</para><para>
@@ -54,7 +54,6 @@
<webAppConfig>
<contextPath>/</contextPath>
</webAppConfig>
<!--scanIntervalSeconds>1</scanIntervalSeconds-->
</configuration>
</plugin>
</plugins></build>
@@ -84,8 +83,8 @@
</para><para>
With this setup we were ready for the first spike: creating a simple MovieController showing a static view. Check. Next was the setup for Spring Data Graph.
We looked at the README at github and then checked it with the manual. Quite a lot of maven setup for aspectj but otherwise not so much to add.
Time to add a few lines to our spring configuration.
We looked at the README at github and then checked it with the manual. Quite a lot of Maven setup for AspectJ but otherwise not so much to add.
Time to add a few lines to our Spring configuration.
</para><para>
@@ -129,7 +128,7 @@
</example>
</para><para>
We spun up jetty to see if there were any obvious issues with the config. Check.
We spun up Jetty to see if there were any obvious issues with the config. It all seemed to work just fine. Check.
</para>
</section>
</chapter>

View File

@@ -1,16 +1,17 @@
<?xml version="1.0" encoding="UTF-8"?>
x<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.docbook.org/xml/4.4/docbookx.dtd">
<chapter id="tutorial_about-spring-data">
<title>Conjuring Magic - Spring Data Graph</title>
<para>
But that was the pure graph database. Using this in our domain would pollute my classes with lots of graph
That was the pure graph database. Using this in our domain would pollute our classes with lots of graph
database details. We don't want that. Spring Data Graph
promised to do the heavy lifting for us. So we checked that next. Obviously it heavily depended on aspectj magic.
So there would be certain behavior that was
just observable without being visible in our code, but we were going to give it a try.
promised to do the heavy lifting for us. So we checked that next.
Spring Data Graph depends heavily on AspectJ magic. Some parts of our classes would behave differently,
but it would not be visible in our code. We were going to give it a try.
</para>
<para>
First step was lots of maven configuration.
First step was lots of Maven configuration.
<programlisting language="xml"><![CDATA[
<properties>
@@ -71,7 +72,7 @@
</plugin> </plugins> </build>
]]></programlisting>
</para><para>
The spring configuration was much easier, thanks to a provided namespace.
The Spring configuration was much easier, thanks to a provided namespace.
</para><para>
<programlisting language="xml"><![CDATA[
<beans xmlns="http://www.springframework.org/schema/beans" ...