Annotations and auto-entities

[jadell]

Start looking at annotations, possibly following the Spring Data Graph syntax. Look to Doctrine2 for inspiration.

[dannykopping]

I've written a very simple lib for parsing PHP DocBlocks (annotations, et al) https://github.com/dannykopping/PHPDocBlock-lite

I'm new to neo4jphp, but maybe I can help out with this once I'm more familiar with Neo4j and this lib

[jadell]

I'll check it out.

There will need to be some meta data attached to some of the annotations. Can the library handle annotations that look like: @Annotation(key1=value1, key2=value2)

Thanks for your interest!

[dannykopping]

Hhmm, I don't think so - I followed the standard PHP annotation standard:

/**
* @annotation    key1=value1, key2=value2
*/

It will return an array of annotations, split by the annotation name and the value (usually separated by x number of spaces or tabs)

[jadell]

The value could be a JSON string, which could then be parsed:

/**
 * @annotation {"key1":"value1", "key2":"value2"}
 */

It's a little more verbose, but it would make things easier to parse. Even better if it could be formatted over multiple lines:

/**
 * @annotation {
 *   "key1":"value1",
 *   "key2":"value2"
 * }
 */

I'm going to evaluate a few different libraries, mainly for ease-of-use and speed before I start on this. Yours is one, there's also the Doctrine Annotation library, and one or two others.

I really wish PHP had native annotation support.

[THemming]

How about going all in and creating a new Doctrine library based on log4jphp for Object to Graph Mapping? There are now Doctrine libraries being developed for mapping Document stores, XML and Content Repository (PHPCR). I think the next logical addition would be an Object Graph Mapper (OGM) sharing the same libraries, resources and API design as the other mappers.

Doing this would give you the PSR-0 autoloader and the annotation library right out the box. Also it'd improve the community exposure to your project.

Agreed, wish PHP had native annotations. Maybe in PHP 5.5, but not looking likely at the moment.

[jadell]

I've been investigating that possibility since I created this issue. I just haven't had time to get any further than forking the Doctrine MongoDB connector as a starting point. I wouldn't be opposed to some help :-)

[THemming]

Yes I'd imaging if it were to be a Doctrine project it would actually be the Doctrine Neo4j connector but could use a common Object Graph Mapper component shared with other, future, graph databases (i.e. OrientDB).

I think pushing this as a potential Doctrine project might drum up support and contributions but I don't have any idea of the effort involved in getting it approved by the Doctrine leads. I have been looking for an open source project to contribute towards but have a new born at home so need things to settle down there a bit first.

[lphuberdeau]

I started writing something similar for my project. It uses neo4jphp in the background, but uses a Doctrine2-style interface instead with an entity manager and repositories to query with gremlin/cypher. It is not fully featured, but does quite a lot. I'd be willing to make it publicly available if there is some interest.

[jadell]

I'd be interested in checking it out. Does it use the actual Doctrine2 libraries?

[lphuberdeau]

I use some parts of Doctrine\Common, namely the annotation readers and the array collection. My goal was not as much to write something for all databases and part of the doctrine framework, but to have my code using Neo4j to feel like the rest of the code using Doctrine2. Entities are mapped using custom annotations and the entity manager essentially provides persist() and flush(). The repositories will map findBy* to search indexes and can be extended to run custom Gremlin/Cypher queries, for which results get mapped to entities when nodes are returned.

I have made an effort to keep this separate from my main codebase but some of the test coverage comes from the main codebase rather than dedicated tests. I could fork your repository and add the code to it. I would be glad to see it merged with neo4jphp for everyone to use.

[jadell]

Wow! That is essentially what I was planning to do, I just never have gotten the time to do it. If you get a chance, please set this up as a separate project that I can clone and play around with.

[lphuberdeau]

I will try to do this one evening or on the week-end.

[lphuberdeau]

https://github.com/lphuberdeau/Neo4j-PHP-OGM

[jadell]

@lphuberdeau Would it be cool if I used this as a starting point but changed some things around? There are a few specific things I would like to change:

a) move it into the Everyman namespace to avoid an external dependency b) make the syntax closer to the Spring Data Graph syntax (http://static.springsource.org/spring-data/data-graph/snapshot-site/reference/html/#reference:programming-model:annotations) so that experience with one can easily port over to the other c) Use the actual Doctrine base classes and interfaces

How does any of that sound to you?

[lphuberdeau]

@jadell This is all work in progress that evolved from my needs, not a solution that was designed up front.

a) If it is to be incorporated in the main codebase, it makes sense. If not, I see no reason. I was planning on moving to composer for this and it makes all the namespace and dependency management trivial.

b) I did look at it, however my goal was to be closer to Doctrine rather than to Spring.

c) I did not look at the base classes in details. For the moment, only a subset of operations are supported. For example, no nodes or relations are ever removed. It uses some pieces of Doctrine-Common, but I can't say it supports the base interfaces. There are also bigger changes to be fully compliant to the Doctrine interfaces, like generating proxy classes rather than just using a decorator like what is done now. I think getting closer to Doctrine and its base classes and interfaces is a good long term road map for this project.

[jadell]

The plan is to keep neo4jphp fairly low level in talking to the REST API. Spring- or Doctrine-like annotations are outside the scope of this. An eventual improvement will be to make the HTTP transport layer independent of the Node/Relationship objects at the higher level. This way, clients can choose for themselves if they want to use the full Node/Relationship objects, or just the REST layer with their own mappings on top.