-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for Neo4j 2.0 indexes over label #53
Comments
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,
By "consistency" you mean backward-compatibility with v1.x? 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 That being said, for code readability reasons, I would introduce a new keyword such as
|
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?
The text was updated successfully, but these errors were encountered: