OK. Started testing along this route. One additional question. I will typically want paginated access to the facts. It wouldn’t be efficient (or necessarily useful) to return all the facets at once. So, if I’m looking for city values where node has property x=foo and y= bar and outgoing relationship of type address to node with city, how can I get paginated access to all city values, sorted by the city property?
-------------------- Clark Richey, CTO FactGem 240-252-7507<tel://240-252-7507> [email protected]<mailto:[email protected]> [cid:C1F651FF-2D4A-4D09-9B5A-1F9B56D2922C] Need immediate assistance? Please try: Cate Downing, Assistant Beth Price, Assistant [email protected]<mailto:[email protected]> [email protected]<mailto:[email protected]> 614.325.2404<tel://614.325.2404> 614.365.0740<tel://614.365.0740> This message and any included attachments are property of FactGem and its affiliates, and are intended only for the addressee(s). The information contained herein may include trade secrets or privileged or otherwise confidential information. Unauthorized review, forwarding, printing, copying, distributing, or using such information is strictly prohibited and may be unlawful. If you received this message in error, or have reason to believe you are not authorized to receive it, please promptly delete this message and notify the sender by e-mail. Thank you. On June 24, 2014 at 7:50:24 AM, Michael Hunger ([email protected]<mailto:[email protected]>) wrote: This is kind of a faceted search. depends on the selectivity something like gender I would neither put in an index nor connect to a "gender" node, both would just refer to half you data which is not selective at all, so I would put these as property on the node For others like city, income group, interests etc. I'd use "attribute"-nodes, then either look up the attribute node from the index and check if your current node is connected to it or just do lookup what node your node is connected to via the "lives_in" relationship and check properties on the end node. HTH, Michael Am 24.06.2014 um 11:29 schrieb Clark Richey <[email protected]<mailto:[email protected]>>: Ok just so that I'm 100% clear you are saying looking the first node from indexes and do a traversal and that it should be fast even if the query is actually something like find people with gender male married to a person with income between 40 and 60k who has a residence in the city of Columbus? In this case looking up people that are male will return LOTS of nodes as might even the second step in the traversal. Sent from my iPhone On Jun 24, 2014, at 0:48, Michael Hunger <[email protected]<mailto:[email protected]>> wrote: Depending on selectivity Lookup by x or y from index Check the other props and rels You might also lookup columbus and check >From node to columbus It is a local traversal then should be fast Sent from mobile device Am 24.06.2014 um 03:51 schrieb Clark Richey <[email protected]<mailto:[email protected]>>: All, I am writing server side extensions to neo4J. I need to be able to find nodes that match a graph pattern similar to: node has property x=foo and y= bar and outgoing relationship of type address to node with city=columbus. That could even extend another node out. I know I can find one end of the above relationship and then filter but this doesn’t work well when the pattern I want to match is more like node a -> node b -> node c with various property lookups on each node. This is also a large graph so starting at any given node could easily yield a million nodes from which to start a traversal. Thanks for the help! -------------------- Clark Richey, CTO FactGem 240-252-7507<tel://240-252-7507> [email protected]<mailto:[email protected]> Need immediate assistance? Please try: Cate Downing, Assistant Beth Price, Assistant [email protected]<mailto:[email protected]> [email protected]<mailto:[email protected]> 614.325.2404<tel://614.325.2404> 614.365.0740<tel://614.365.0740> This message and any included attachments are property of FactGem and its affiliates, and are intended only for the addressee(s). The information contained herein may include trade secrets or privileged or otherwise confidential information. Unauthorized review, forwarding, printing, copying, distributing, or using such information is strictly prohibited and may be unlawful. If you received this message in error, or have reason to believe you are not authorized to receive it, please promptly delete this message and notify the sender by e-mail. Thank you. -- 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]<mailto:[email protected]>. For more options, visit https://groups.google.com/d/optout. <DB3DED71-9092-4039-BC47-7254B572F9D5> -- 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]<mailto:[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]<mailto:[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]<mailto:[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.
DB3DED71-9092-4039-BC47-7254B572F9D5
Description: DB3DED71-9092-4039-BC47-7254B572F9D5
