Open xbill82 opened 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.
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.
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.
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 ... ])
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
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, alabel
parameter to theIndex
annotation, likeBetter 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
likeor something like that (again, better ideas are welcome).
Sounds cool?