Arguments for ActiveRel.creates_unique, new Association unique options

[subvertallchris]

This is RE: #1035. It forces ActiveRel's creates_unique and Association's unique option to take an argument.

• :none means that all properties are ignored where CREATE UNIQUE is concerned, properties will be set after the rel is created, like our current expectations
• :all means that any property's change will result in a new rel
• {on: [keys]} defines which properties it uses for the match

Called with no arguments or true, it will default to :none.

(This has been edited to reflect the end results. Comments below reflect some earlier content here.)

[subvertallchris]

Just pushed an update to this that makes plain ole' associations' unique option require one of these same arguments. I'm trying to massage things into place so we can reuse more code, so there will be a few more commits.

Rubocop is barking and it needs a little refactoring. I'm going to extract the specifics of how a relationship is built from QueryProxy into a new class tomorrow.

[cheerfulstoic]

Awesome, thanks ;)

I've been thinking about the API and I'm honestly not sure how it will be used, but my thought was that by default you might call creates_unique and it should work like your :none case and then if you specify some arguments those would be equivalent to the {on: [keys]} case. I wonder if the except or :all options would be used much, if at all.

[subvertallchris]

I'm ok with it defaulting to :none but I worry that someone who's used to
Cypher's behavior would expect it to behave like :all.

none and on with keys are ones I expect to be the most useful, but I
added the others since it just felt like they should be there and the code
made it easy enough. ;-)

On Sunday, November 8, 2015, Brian Underwood notifications@github.com
wrote:

Awesome, thanks ;)

I've been thinking about the API and I'm honestly not sure how it will be
used, but my thought was that by default you might call creates_unique
and it should work like your :none case and then if you specify some
arguments those would be equivalent to the {on: [keys]} case. I wonder if
the except or :all options would be used much, if at all.

—
Reply to this email directly or view it on GitHub
#1038 (comment).

[cheerfulstoic]

Regarding people who are used to Cypher, I suspect they're generally going to CREATE UNIQUE with either no or only a small set of properties. The problem is that our API automatically puts in all of the properties/values for you. So thinking about it, I think that even people experienced with Cypher would be surprised at our implementation of creates_unique.

I'm trying to think of what bothers me about the except cases, and I think the problem is that you can have surprising behavior on a team if somebody adds a property. For something that seems like it should be an innocent action, it could have larger consequences. Allowing people to just specify the fields that they want to be used seems safer. Plus it's a cleaner interface because creates_unique without arguments becomes what people would expect it to be (only ever create one relationship between two given nodes) and then you can list out the properties that are important otherwise.

[subvertallchris]

That makes sense. I can remove the Hash aspect of the parameter entirely
and just have it be the Symbol or list of keys. If no argument is given, it
can default to :none, but I'm still not sure it's safe to assume that
everyone will interpret it the way we did. I think we should keep :all as
an option.

On Monday, November 9, 2015, Brian Underwood notifications@github.com
wrote:

Regarding people who are used to Cypher, I suspect they're generally going
to CREATE UNIQUE with either no or only a small set of properties. The
problem is that our API automatically puts in all of the properties/values
for you. So thinking about it, I think that even people experienced with
Cypher would be surprised at our implementation of creates_unique.

I'm trying to think of what bothers me about the except cases, and I
think the problem is that you can have surprising behavior on a team if
somebody adds a property. For something that seems like it should be an
innocent action, it could have larger consequences. Allowing people to just
specify the fields that they want to be used seems safer. Plus it's a
cleaner interface because creates_unique without arguments becomes what
people would expect it to be (only ever create one relationship between two
given nodes) and then you can list out the properties that are important
otherwise.

—
Reply to this email directly or view it on GitHub
#1038 (comment).

[cheerfulstoic]

Sounds good! The only other thing is that I have the slightest of worries that somebody might have a property called all. So maybe all_properties? I dunno, up to you ;)

[subvertallchris]

Let's just stick with a hash, {on: [keys]}, to keep things simple and prevent conflicts. It also gives a path for future filter types if something becomes necessary.

[subvertallchris]

Snuck that in during lunch, will set the default :none tonight and then I think we can merge.

[cheerfulstoic]

Cool ;p

[subvertallchris]

Closed by mistake?

[cheerfulstoic]

Yup, sorry about that!