We are proud to release  Neo4j 2.0.0-M05 as a milestone today. The 2.0 project is now in full speed development after summer vacation. We’re getting close to feature completeness now, and we want to get this release out to you so you can give us refined feedback for the final release.

Unique Constraints
Neo4j values the agility and development speed you get from using a schema-free database. It makes it possible and easy to start prototyping and learning. There is a huge value in this. On the other hand, it’s really nice to be able to make the graph structure more strictly constrained as a project evolves towards production (a big theme in our Neo4j 2.x roadmap). We think the new Optional schema gives you the best of both worlds.

A major step in this direction is the addition of unique constraints. This release includes fully functional unique constraints which allow you to specify that a label/property combination must be unique in a database. Adding constraints make your database safer to work with and catch problems you’d otherwise have to work hard to detect manually.

For example by running this Cypher query, you’ll end up with a unique constraint on the Person label for the email property.


If you try to create two different nodes with the same email, you’ll get an error about it from the database:

CREATE (:Person {email: “dude@company.com”});
CypherExecutionException: Node 2 already exists with label Person and property “email”=[dude@company.com]

In the engine room, unique constraints are implemented using a unique index. You can see this when looking at the schema, for example using the shell:

neo4j-sh (?)$ schema
 ON :Person(email) ONLINE (for uniqueness constraint)

 ON (person:Person) ASSERT person.email IS UNIQUE

Except for the fact you can’t drop the index manually, it works as any other index and can be used for read query execution as well as to check uniqueness.

Label store
Milestone releases prior to this stored labels in the Node store. This meant to find all the nodes with the Person label on them, we would scan the whole node store and look at each node. In the Neo4j 2.0.0-M05 release, we now have a Label store where we persist this information, which makes it faster to find all nodes with a certain label on them.

You don’t need to do anything to make use of this new store — Cypher will automatically use it, and GlobalGraphOperations.getAllNodesWithLabel(Label) will also use it, but don’t be surprised when you see new files in your data/graph.db directory.

AutoClosable transactions
Since Neo4j 2.0 is a Java 7 product, and following our transition to make sure that all resources are tied to a transaction, we’ve changed the age old Transaction interface so that it now implements AutoClosable.

AutoClosable is the interface that allows you to write a try statement, and have an implicit finally block that releases any AutoClosable resources registered with the try block.

This means you can now write to the Core API as follows:

try (Transaction tx = db.beginTransaction()){
  // do stuff inside the transaction

This block will make sure the transaction is closed, even if an exception is thrown inside the try block.

Removed a lot of deprecated methods/classes
Since we’re getting closer to a major release, it’s time to clean up our API a little. In this release, most of the things marked as deprecated in the 1.9 version has been removed so now’s a good time to think about moving any of your code that relies on deprecated methods over to the new APIs.

New Cypher Syntax
Cypher tries hard to work well with not only graphs, but also with collections. In this release, we took the liberty of updating the capabilities we have around collections.

We’ve had functions to do some of these things before, but the queries using them didn’t exactly roll off your tongue. Now we’re trying to make these features easier to use and read once you’ve used them.

Fo more information about ranges, literal maps and list comprehensions, you can read all about it here: http://docs.neo4j.org/chunked/2.0.0-M05/syntax-collections.html

Minimalistic Cypher and JSON
After making the START syntax optional owing to the expressiveness of Labels and the new Indexes, we now are also making WHERE and MATCH optional if you don’t need variables at all. And you now can return literal maps directly, making Cypher way more JSON-friendly

RETURN { key : “Value”, collectionKey: [ { inner: “Map1” }, { inner: “Map2” } ] } as JSON
is now perfectly valid syntax.

Deprecated > /dev/null
We have now removed a number of deprecated APIs from Neo4j, as announced at least 2 versions earlier, see the changelogs.

As always, we’re done a bunch of bugfixes and performance improvements, the release notes.

Also, a big thanks for all the good suggestions, discussions and error reports that have gone into this release. It makes a big difference!

Yours connectedly,

Andres Taylor
Andres Taylor

Want to learn more about graph databases? Click below to get your free copy of O’Reilly’s Graph Databases ebook and discover how to use graph technologies for your application today.

Download My Ebook



Ekin Öcalan says:

Excited for the major release; it&#39;s getting better and better. :)<br /><br />One thing though: You said START clause is going to be optional; so do we able to run older queries in 2.0 also?

Hi Ekin,<br /><br />START is going to be optional, not removed, in Neo4j 2.0. Long term, this might change, but for now, there are no specific plans to remove it.

Hi all ! <br />Constraining the DBs is a huge step towards a deserved victory. My congratulations !!<br />Though, did this affects nodes&#39; creation performances ?<br />Indeed, is there any documentation around the query language you&#39;re using ?<br /><br />Good job guys! Keep it up !<br /><br />Cheers

Bob says:

When will be Debian Package be release for M05?

Anonymous says:

WHERE IS Rassilon?

Hi Amine,<br /><br />Thanks – we share the feeling that this is an important step.<br /><br />It does affect performance, at least if you are creating nodes that will be indexed. Because indexes need to be transactionally consistent, we must take the time to update the indexes at commit time.<br /><br />The query language is documented here:<br />http://docs.neo4j.org/chunked/snapshot/

Bob,<br /><br />The Debian packages should be available. If you are still having problems with them, I suggest you ask for help on Stackoverflow – that&#39;s where we try to consolidate all the user support.<br /><br />Hope it works out for you!

Leave a Reply

Your email address will not be published. Required fields are marked *