lphuberdeau / Neo4j-PHP-OGM

A doctrine2 style library to access neo4j graphs
156 stars 45 forks source link

Support for Neo4j 2.0 indexes over label #53

Open xbill82 opened 10 years ago

xbill82 commented 10 years ago

Hi everybody, as you can see here, Neo4j 2.0 offers the ability to easily define indexes over properties of nodes tagged with a given label: for instance

CREATE INDEX ON :Crew(name);

and this major change should be taken into account by the OGM. One issue is that the Neo4j-PHP layer does not support this yet, but the feature should be coming soon (if I properly understand the green bar in here ).

Concerning the OGM, as far as I can see Entities accept labels and properties accept @OGM\Index annotations, which is good. Still, there is a little bit of ambiguity when the Entity is tagged with many labels, but this can be easily solved by adding, for example, a label parameter to the Index annotation, like

@OGM\Index("MyPrettyLabel")

Better ideas are welcome for this.

My last doubt is: since the indexes are no more correlated with the node creation, when does the OGM create/update the indexes? A possible solution could be the introduction of a console command similar to the php app/console doctrine:schema:update like

php app/console ogm:schema:update

or something like that (again, better ideas are welcome).

Sounds cool?

lphuberdeau commented 10 years ago

For consistency, I think there should be a key associated to the Index annotation for this purpose, or use a different annotation entirely to avoid mixing up the different index types. I'm a little off beat with Neo4j development, so I will have to trust you on the details.

It's true that until now, there was no step for index creation, but perhaps it could be added. I don't see why we would not want it.

Feel free to send PR, we can discuss from actual code.

xbill82 commented 10 years ago

Hi Louis-Philippe, I don't really understand your first sentence:

For consistency, I think there should be a key associated to the Index annotation for this purpose, or use a different annotation entirely to avoid mixing up the different index types.

By "consistency" you mean backward-compatibility with v1.x? By "key associated to the index annotation" you mean the name of the label upon which the index should be created? By "different index types" you mean the NodeIndex != RelationIndex (i.e. the v1.x-fashion indexes) or the V1.xIndex != V2Index? (sorry for the avalanche of questions... I'm quite new to the repo)

Personally, I would avoid mixing the new 2.0 features with the 1.9 ones in the code, especially the ones that concern indexes. IMHO the repo should be branched in order to have a "v1.x compatible" branch and continue the HEAD development for v2.0. This would allow a smooth transition for the guys who have huge DBs and don't plan to migrate to 2.0 immediately. How do you feel about that?

I will submit a PR as soon as the feature is implemented on the Neo4j-PHP side.

lphuberdeau commented 10 years ago

Should be OGM\Index(something="LabelIndex") instead of OGM\Index("LabelIndex").

However, since Index is currently used for value lookups, perhaps OGM\LabelIndex would be better. As I said, I don't know much of the implementation details for those new types of indexes.

As for backward compatibility, if you don't include those new annotations in your schema, things should work out just fine. I'm OK with tagging a release at current state and branching off for older installations. Not sure how many there are that would not be willing to upgrade right away or as soon as possible. Still is a small project.

xbill82 commented 10 years ago

The point of branching the project is basically not having to think about backward compatibility in your master branch: the folks that cannot switch immediately to v2 will still be able to use and maintain the v1.x branch. That's why I wouldn't mind changing the behavior of the OGM\Index keyword in the master branch (if we had to keep syntax consistency among branches, the whole branching thing would become pointless).

That being said, for code readability reasons, I would introduce a new keyword such as

OGM\IndexOnLabel("myAwesomeLabel [, myOtherAwesomeLabel ... ])