Judging by this merge <https://github.com/neo4j/neo4j/commit/71760230b3fc300d9f7fee8bc2d3382897b87132>, I take it this is a bug in the sense that it's not something Neo4j should permit. Are there any plans to allow multi-index querying/hiinting per identifier in future versions?
~A On Mon, Jun 9, 2014 at 11:14 AM, Andres Taylor < [email protected]> wrote: > This looks like a Cypher bug. Will investigate! > > > On Mon, Jun 9, 2014 at 3:16 PM, Aru Sahni <[email protected]> wrote: > >> I've experimented with this all weekend and haven't made any progress. >> Due to deadlines I've just moved forward with having neo4j just use one >> index, and taking db_hits for the subsequent lookups. Is this a neo4j bug? >> >> ~A >> >> >> On Fri, Jun 6, 2014 at 2:36 PM, Aru Sahni <[email protected]> wrote: >> >>> I just upgraded to 2.0.3 and can verify the same behavior. >>> >>> ~Aru >>> >>> >>> On Fri, Jun 6, 2014 at 2:19 PM, Michael Hunger < >>> [email protected]> wrote: >>> >>>> Can you try to verify the behavior in 2.0.3 or 2.1.1 ? >>>> >>>> >>>> On Fri, Jun 6, 2014 at 8:12 PM, Aru Sahni <[email protected]> wrote: >>>> >>>>> 2.0.1 >>>>> >>>>> ~Aru >>>>> >>>>> >>>>> On Fri, Jun 6, 2014 at 2:09 PM, Michael Hunger < >>>>> [email protected]> wrote: >>>>> >>>>>> Which version are you using? >>>>>> >>>>>> >>>>>> On Fri, Jun 6, 2014 at 8:00 PM, Aru Sahni <[email protected]> wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> My simplified data model is as follows: >>>>>>> >>>>>>> Entity { >>>>>>> source} >>>>>>> Person { >>>>>>> first_name} >>>>>>> >>>>>>> And I have the following indexes: >>>>>>> >>>>>>> ON :Entity(source) ONLINE >>>>>>> ON :Person(first_name) ONLINE >>>>>>> >>>>>>> I've got a handful of nodes on my graph. Each node has two labels, >>>>>>> Entity and Person. I want to query for all people with a given source >>>>>>> that >>>>>>> have a certain first name. The naive way of doing this is: >>>>>>> >>>>>>> MATCH (n:Person) >>>>>>> WHERE n.first_name = 'John' AND n.source = "form1" >>>>>>> RETURN n; >>>>>>> >>>>>>> The profiler shows: >>>>>>> >>>>>>> Filter(pred="Property(n,source(10)) == Literal(form1)", _rows=2, >>>>>>> _db_hits=2) >>>>>>> SchemaIndex(identifier="n", _db_hits=0, _rows=2, label="Person", >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> query="Literal(John)", identifiers=["n"], property="first_name", >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> producer="SchemaIndex") >>>>>>> >>>>>>> So, obviously it's not using the Entity(source) index. Time to >>>>>>> declare it. >>>>>>> >>>>>>> MATCH (n:Entity:Person) >>>>>>> USING INDEX n:Person(first_name) >>>>>>> USING INDEX n:Entity(source) >>>>>>> WHERE n.first_name = "John" AND n.source = "form1" >>>>>>> RETURN n; >>>>>>> >>>>>>> The profiler shows that it's hitting both indexes: >>>>>>> >>>>>>> SchemaIndex(identifier="n", _db_hits=0, _rows=8, label="Entity", >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> query="Literal(form1)", identifiers=["n"], property="source", >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> producer="SchemaIndex") >>>>>>> SchemaIndex(identifier="n", _db_hits=0, _rows=2, label="Person", >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> query="Literal(John)", identifiers=["n"], property="first_name", >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> producer="SchemaIndex") >>>>>>> >>>>>>> However, the returned rows appear to show records with >>>>>>> first_name=John OR source=form1. There are duplicate nodes returned as >>>>>>> well, but nothing DISTINCT can't fix. >>>>>>> >>>>>>> Switching the order of the USING statements still duplicates result >>>>>>> nodes, but they seem to reflect the proper intersection. >>>>>>> >>>>>>> Any insight into this behavior (and guidance) would be greatly >>>>>>> appreciated. >>>>>>> >>>>>>> Regards, >>>>>>> ~Aru >>>>>>> >>>>>>> -- >>>>>>> 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 [email protected]. >>>>>>> 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 [email protected]. >>>>>> 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 [email protected]. >>>>> 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 [email protected]. >>>> 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 [email protected]. >> 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 [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
