Require id property

[cheerfulstoic]

It friggin' works!

Require that id_property is called for all models. Default to former behavior of auto: :uuid when id_property :field is called

[cheerfulstoic]

When I say it works, I should clarify that the specs pass. Going to try it in an actual app now ;)

[cheerfulstoic]

Note: first/last/etc... should use uuid, not ID()

[andreasronge]

Really nice work !
Do you mind rebase/squash all those commits so we get a nice git history.
It would be really nice if we did not have to write id_property for all models. I guess you have tried to fix this and I understand that it could be really tricky to fix it.

[subvertallchris]

Couldn't id_property be called in an included do block in one of the other modules? It's working fine for me here.

Sorry if that's already been discussed, I'm coming into this kind of late. :-)

[cheerfulstoic]

@subvertallchris I think tried that, but please let me know if I missed something ;) The problem is that you can call id_property in the included block but then if the model defines an id_property it's now been called twice. When do the constraints get created? Currently in master they would (I think) get created twice. Really what we want is to do all of the setup after that last id_property is called and before the model starts getting used (I don't think it's very good to do the setup when the model is first used because you'd need to hook that in in a lot of places and because you might be in a transaction in which the neo4j server will complain that you're changing the schema (the constraint) and the data at the same time inside of a transaction (a no-no))

[cheerfulstoic]

@andreasronge Yup, I agree. If you come up with a way to not do that, I would be so happy ;)

[subvertallchris]

Ahh, now I see! I did see a few of your comments where you mentioned difficulty with the constraint but it was just bits and pieces so I couldn't quite place it. I guess it works fine for my gem since the whole idea is that it's there for global use and the user won't be declaring it twice.

[subvertallchris]

Is declaring it a second time really a problem if they aren't trying to define a constraint on the same property? That is to say, if they are defining a different id_property, that's just an additional unique constraint, and what harm is there in that? The first one is still there but it doesn't matter unless they try to reuse that property name as a vanilla non-unique property, which we can prevent by adding any already-declared id properties to the list of restricted property names.

(The word "property" appears too many times in this comment.)

[cheerfulstoic]

A good question. Maybe not if unique constraints don't constrain null/non-existant values, but it still seems somewhat messy polluting users' databases with unnecessary constraints.

Another thing that I thought of that I didn't really explore is having some call which is required to start using the models. So the models are all defined and then you call something like Neo4j.use_models which sets up all the constraints and whatnot.

[subvertallchris]

In that case, what about using Cypher to drop the existing constraint in the event the user declares id property on the model? DROP CONSTRAINT ON (u:User) ASSERT u:_id IS UNIQUE

[cheerfulstoic]

Huh, you know, that's not a bad idea ;) I just did that in the specs to make sure the test database is cleared out when re-used ;)

I'm off to sleep now and I'm going to be out exploring Paris tomorrow (sans ordinateur portable), but I'll think about that and likely implement that.

Also for @andreasronge I agree about the rebase/squash and will do that when I'm done

[andreasronge]

@subvertallchris sounds like a good solution. I guess setting the index constraints twice only occurs if there is already a session available since it will otherwise be delayed until session is available, see Neo4j::Session.on_session_available method.

[subvertallchris]

Two thoughts:

1. With this, I think version should be bumped to 3.1.0.alpha.rc.1 and we should skip a proper 3.0 release. We know there are people developing on the old alphas already and this is a breaking change that will immediately orphan all data in existing databases.
2. I think we should hold off on merging this in until there is an accompanying migration rake task to add new IDs and classnames to existing nodes. It can be a list of labels and the classnames to assign. This will ensure nothing gets left behind and will provide a roadmap for those who are ready to upgrade.

[cheerfulstoic]

Started over with PR #478