I feel that MERGE or no MERGE, neo4j should always keep this constraint. So to me it absolutely feels like a bug where neo4j fails to detect the constraint violation. I'd love to try and reproduce to see where the problem is.
On Wed, Sep 17, 2014 at 3:31 PM, Saad Mufti <saad.mu...@gmail.com> wrote: > I don't understand, of what use is the uniqueness constraint then if it > can be violated so easily if you use the CREATE cypher command? > > MERGE will not work for us because we are trying to create two logically > separate nodes while ensuring that they have unique segment id's, and want > the constraint to throw an error if we happen to violate the uniqueness > constraint. Is the Neo4J constraint not useful for that use case? > > Thanks. > > ---- > Saad > > On Tuesday, September 16, 2014 5:57:00 PM UTC-4, Michael Hunger wrote: >> >> MERGE is the only cypher operation that guarantees uniqueness and also >> takes the necessary machine- and cluster-wide locks to assure that. >> >> Cheers, Michael >> >> On Tue, Sep 16, 2014 at 11:50 PM, Saad Mufti <saad....@gmail.com> wrote: >> >>> We're already writing to the master. >>> >>> What do you mean by "with appropriate locks"? We're using Cypher over >>> REST hitting the transactional endpoints as documented at: >>> >>> http://docs.neo4j.org/chunked/stable/rest-api-transactional.html >>> >>> I don't see anything documented there to allow obtaining of any kind of >>> lock over the REST API. >>> >>> We are not using MERGE, will use that and update this thread. >>> >>> Thanks. >>> >>> ---- >>> Saad >>> >>> >>> On Tuesday, September 16, 2014 5:31:27 PM UTC-4, Michael Hunger wrote: >>>> >>>> Also I recommend that you focus writing to the master and not the >>>> slaves for higher performance. >>>> >>>> Feel free to raise a support ticket with our Neo Technology customer >>>> account when the issue persists with MERGE >>>> >>>> On Tue, Sep 16, 2014 at 11:29 PM, Michael Hunger < >>>> michael...@neotechnology.com> wrote: >>>> >>>>> To assure uniqueness across multiple threads and a cluster (with >>>>> appropriate locks, please use MERGE) >>>>> >>>>> MERGE (n:SEGMENT {segmentId : 110484}) ON CREATE SET n.name = "name" >>>>> , ....; >>>>> >>>>> >>>>> On Tue, Sep 16, 2014 at 11:15 PM, Saad Mufti <saad....@gmail.com> >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> We have a Neo4J 2.1.3 database and we have a uniqueness constraint >>>>>> that was created as follows: >>>>>> >>>>>> CREATE CONSTRAINT ON (segment:SEGMENT) ASSERT segment.segmentId IS >>>>>> UNIQUE >>>>>> >>>>>> When we test this from the browser, it works fine in detecting >>>>>> violations, e.g: >>>>>> >>>>>> CREATE (n:SEGMENT {name : "duplicate", segmentId : 110484}) RETURN n >>>>>> >>>>>> results in >>>>>> >>>>>> Node 589 already exists with label SEGMENT and property >>>>>> "segmentId"=[110484] >>>>>> >>>>>> Neo.ClientError.Schema.ConstraintViolation >>>>>> >>>>>> which is fine. >>>>>> >>>>>> We have a load tester setup with 3 machines and multiple threads per >>>>>> box using Cypher over REST talking to Neo4J and using the transactional >>>>>> endpoints to do creates similar to above (but of course many more >>>>>> properties relevant to our app), and always writing to the Neo4J master >>>>>> in >>>>>> an HA setup. >>>>>> >>>>>> We can reliably reproduce in that setup multiple violations of the >>>>>> uniqueness constraint that are NOT caught by Neo4J, they execute without >>>>>> error and in the resulting db we can see multiple nodes with the SEGMENT >>>>>> label and the same value for the segmentId property (we are intentionally >>>>>> generating duplicate segmentId values for our test). >>>>>> >>>>>> Anyone else run into the same issue? Is this a Neo4J bug? >>>>>> >>>>>> Thanks. >>>>>> >>>>>> ----- >>>>>> Saad >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Neo4j" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to neo4j+un...@googlegroups.com. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Neo4j" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to neo4j+un...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > You received this message because you are subscribed to the Google Groups > "Neo4j" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to neo4j+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Mattias Persson Neo4j Hacker at Neo Technology -- You received this message because you are subscribed to the Google Groups "Neo4j" group. To unsubscribe from this group and stop receiving emails from it, send an email to neo4j+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
