Re: [Neo4j] Traversal RelationshipExpander
Thanks for your suggestions regarding my model, Craig. I agree about the ids. Using a generalization for Asset Types might be something to look at. I'm still stuck on wanting to capture the general nature of an Asset as well as the specific triple of Producer-Asset-Consumer. I'll have to think about your statement that Asset is specific to a Producer. In my current model, an Asset may have multiple Producers and multiple Consumers. The concept of an Asset is more general than a single Producer-Consumer relationship. Maybe it's appropriate to duplicate the Asset node (not the actual node but the properties that identify an Asset). My relational DB mind doesn't want that kind of duplication. Some of the questions I want to answer: 1. Given a Consumer, what Assets does it subscribe to? 2. Given a Consumer, what Producers is it dependent upon? 3. Given a Producer, what Assets does it contribute to? 4. Given a Producer, what Consumers are dependent on it? 5. Given an Asset, what Producers contribute to it and what Consumers subscribe to it? There's other node types and properties within the graph that aren't important or that I can't discuss (this is a mock model anyway). What is the consensus about duplicating node data within a network? I can see how using indexing or a hierarchy, as you've pointed out, might help with that. Part of my hangup is that I'm looking at using Neo4J as an adjunct to a RDBMS to store dependency relationships. Each node will have information that ties back to the RDBMS for lookups. But that doesn't require absolutely unique nodes. Keeping the two DBs in sync will be a challenge but I don't have the option to push all of the data into Neo4J and I'd rather not manage the dependencies in the RDBMS. Actually, now that I've talked around it, I think I see how your model would work for what I want to do. I'd have to see how a Traverser would return the results. Thanks for your time, Kalin On Nov 24, 2010, at 4:50 PM, Craig Taverner wrote: Hi, I also do not like having the producers ids in the relationship. This is like having an non-indexed foreign key. I think the right solution is to change the database structure to match the intention of the model. I'll go out on a limb here and make some assumptions about what you really mean by your model. You want to ask 'who consumes assets by this producer'. Your problem is that what you are calling an Asset is actually a type of Asset, but some consumers are interested in a specific asset, not just all assets of that type, and so you are having to add extra data to resolve the type in the 'subscribes' relationship. A far better solution is to have a real asset node. By that I mean a 'ford mustan '68' node instead of a 'car' node. Then the case where the subscribes node has no producers property really means the Consumer subscribers to the AssetType, and the case where there are producers properties, the Consumer subscribers to those specific Assets (where Asset is now specific to a producer). Then the model will have no foreign keys, only relationships, and a plain old standard out-the-box traverser will give you your answer :-) Some further clarifications of the relationships I see in the graph: - Assets can have IS_A relationships to AssetTypes - Produces CONTRIBUTE_TO Assets, never AssetTypes (just like Ford produces the 'Ford Mustang', not 'cars') - Consumers can SUBSCRIBE_TO either Assets directly (ie. specific models), or AssetTypes (this deals with your two cases before, but no longer needs ids in properties) The traverser can traverse directly from the Producer to the Subscriber without any complications. Just follow the right relationships in the right order, and only return Subscribers. The paths could look like: Producer1 --(contributes_to)-- AssetX --(subscribes_to)-- Consumer1 | (IS_A) | V AssetTypeP --(subscribes_to)-- Consumer2 Notice that traversing to consumers that are subscribing to specific assets (assets by specific producers) is a shorter path than traversing to consumers that subscribe to assets by any producer (asset types). This should have no impact on the traverser. Just remember to include the IS_A relationships type (with the right direction) to get the results you want. Cheers, Craig On Thu, Nov 25, 2010 at 12:00 AM, Mattias Persson matt...@neotechnology.com wrote: Hi Kalin, To begin with I'm not fond of storing ids as properties... that's what relationships are for. So I'd perhaps insert a middle node between Asset and Consumer which then also can have relationships to Producers. Anyways, to get that behaviour you can use a filter which will exclude unwanted paths. Traversal.description().uniqueness(RELATIONSHIP_PATH)
[Neo4j] Modeling inheritance in Neo4J
Hi, I'm looking for best practices in modeling inheritance in Neo4J. Suppose I have a Person class. In the DB I naturally have a node for each person. I'm following the design guide, and created a PEOPLE subreference node, connected to all Person nodes (A and B in the diagram below) +--- A | REF -- PEOPLE --+ | +--- B Now suppose I introduce a User class, that extends Person. I thought about a couple of options: 1. I could just connect the user nodes to the PEOPLE node, but then it would be more difficult to traverse only users. 2. Adding another layer of sub-referencing +--- USERS +-- C | | REF -- PEOPLE --+ +-- D | +--- NONUSERS -+-- A | +-- B So there's the USERS node that is connected to all user nodes, and a NONUSERS node that is connected to all of the concrete Person nodes. This way the Person and User factories handle the connections to each subreference node. The downside of this is that as I introduce more types in the class hierarchy I need to start rewiring everything, which can be quite tedious at present and very costly in the long run. 3. Perhaps a better way is to avoid the NONUSERS node, keep the concrete People (A and B in this example) connected to the PEOPLE node [Option2]: +--- USERS +-- C | | REF -- PEOPLE --+ +-- D | +---+-- A | +-- B Of course, I'd use different relationship types so I can tell between people and and subreferences connected to PEOPLE. I'm sure these aren't the only ways, and there may be different ways to handle different cases. In any event, I'd appreciate your feedback, as well as any additional tips related to inheritance. Also, if there's any Neo4J guide for managing inheritance that I missed, it would be great if someone would point me out to it. Thanks, --- Yaniv ___ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo4j] Traversal RelationshipExpander
Hi Kalin, I'm not sure I follow about duplicating. The suggestion I made did not involve any duplicating. The AssetType nodes would contain properties appropriate to the type of asset, and the Asset node would contain properties only appropriate to that instance (or none if none are appropriate). Perhaps it is easier if I rather revert back to your original names, and use Asset for the type again, and come up with a new name for the specific instance? Then you get something like: Producer[1] --(contributes_to)-- [X] --(subscribes_to)-- Consumer1 | (IS_A) | V Asset[P] --(subscribes_to)-- Consumer2 Now you can see that the X is really just like a join table in a relational database. In fact my suggestion is very similar to a common refactoring that occurs in a relational database when you have a foreign key to another table and then need to add properties to that relationship, you create an intermediate 'join table' and add the properties there. I definitely still think you will need to expand your producer-asset-consumer triple to be a producer-x-asset-consumer, where the 'x' is the 'join table' that allows a consumer to subscribe to assets by a particular producer. Which is what you want, right? I will answer, based on my model suggestion, each of the queries you ask below: 1. Given a Consumer, what Assets does it subscribe to? Traverse from consumer along both outgoing 'subscribes_to' and outgoing 'is_a' relationships, and you will get all assets regardless of whether the consumer subscribes to the asset in general, or the specific producer-asset. 2. Given a Consumer, what Producers is it dependent upon? Traverse from consumer along outgoing 'subscribes_to', incoming 'is_a' and incoming 'contributes_to' relationships, and you will get all producers of all assets (specific or otherwise) that the consumer subscribes to. 3. Given a Producer, what Assets does it contribute to? Traverse from producer along outgoing 'contributes_to', and outgoing 'is_a' relationships, and you get the Assets they they contribute to. 4. Given a Producer, what Consumers are dependent on it? Traverse from producer along outgoing 'contributes_to', outgoing 'is_a' relationships and incoming 'subscribes_to' and you get all Consumers that depend on assets that producer contributes to. This one is more subtle, though, because it depends on what you mean by 'dependent on'. Since the traverser I described will not exclude consumers that subscribe_to assets that are produced by both the given producer and others also (giving the consumer the choice of producer). If you only want consumers that have no choice, leave the 'is_a' relationship out of the traverser. 5. Given an Asset, what Producers contribute to it and what Consumers subscribe to it? For producers traverse on incoming 'is_a' and incoming *contributes_to'. For consumers traverse on incoming 'is_a' and incoming 'subscribes_to'. There's other node types and properties within the graph that aren't important or that I can't discuss (this is a mock model anyway). Hopefully the fact that I renamed my AssetType back to your original Asset, and have a new 'join table', possibly called 'producer-asset' for the additional concept I added before will make it easier to see how to fit this model into your existing structures. What is the consensus about duplicating node data within a network? I can see how using indexing or a hierarchy, as you've pointed out, might help with that. Part of my hangup is that I'm looking at using Neo4J as an adjunct to a RDBMS to store dependency relationships. Each node will have information that ties back to the RDBMS for lookups. But that doesn't require absolutely unique nodes. Keeping the two DBs in sync will be a challenge but I don't have the option to push all of the data into Neo4J and I'd rather not manage the dependencies in the RDBMS. I dislike duplicating data in neo4j as much as I dislike duplicating it in a RDBMS. I'm sorry if I gave the impression in my previous email that I was suggestion duplication. My suggestion was just the addition of this 'join-table' idea (an extra node in the graph), so make it possible to capture the concept of a consumer subscribing to an asset and an asset by a particular producer. Actually, now that I've talked around it, I think I see how your model would work for what I want to do. I'd have to see how a Traverser would return the results. Thanks for your time, Super. Perhaps I should have read your complete mail before writing this new one or hopefully the new one, especially all the traverser suggestions, has helped clarify further ? :-) Regards, Craig ___ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo4j] Modeling inheritance in Neo4J
Another factor to consider is multiple inheritance, where you are grouping the people into overlapping groups. For example, you can have the users/non.users split, but also perhaps a man/woman split, and this results in four types. If you are concerned about having to restructure the graph when adding new types, then I would suggest using a tag approach. This means you forget about inheritance, keep all person nodes directly under people, and add tags to the person as and when you need to. There are two ways to add a tag: - Have a ref-tags-tag tree along side your ref-people-person tree, and then you can cross link individual tag nodes to person nodes as an when you want. This is very dynamic and easy to maintain. If your GUI allows users to add tags, you can support that also, by adding missing tags if needed. - Use lucene, by adding a tags string property to the person and indexing that. This allows for free-form tagging, but does make the whole thing less definitive. My preference, as usual with such things, is to build a graph for it :-) (ie. the tag tree). On Thu, Nov 25, 2010 at 12:49 PM, Yaniv Ben Yosef yani...@gmail.com wrote: Hi, I'm looking for best practices in modeling inheritance in Neo4J. Suppose I have a Person class. In the DB I naturally have a node for each person. I'm following the design guide, and created a PEOPLE subreference node, connected to all Person nodes (A and B in the diagram below) +--- A | REF -- PEOPLE --+ | +--- B Now suppose I introduce a User class, that extends Person. I thought about a couple of options: 1. I could just connect the user nodes to the PEOPLE node, but then it would be more difficult to traverse only users. 2. Adding another layer of sub-referencing +--- USERS +-- C | | REF -- PEOPLE --+ +-- D | +--- NONUSERS -+-- A | +-- B So there's the USERS node that is connected to all user nodes, and a NONUSERS node that is connected to all of the concrete Person nodes. This way the Person and User factories handle the connections to each subreference node. The downside of this is that as I introduce more types in the class hierarchy I need to start rewiring everything, which can be quite tedious at present and very costly in the long run. 3. Perhaps a better way is to avoid the NONUSERS node, keep the concrete People (A and B in this example) connected to the PEOPLE node [Option2]: +--- USERS +-- C | | REF -- PEOPLE --+ +-- D | +---+-- A | +-- B Of course, I'd use different relationship types so I can tell between people and and subreferences connected to PEOPLE. I'm sure these aren't the only ways, and there may be different ways to handle different cases. In any event, I'd appreciate your feedback, as well as any additional tips related to inheritance. Also, if there's any Neo4J guide for managing inheritance that I missed, it would be great if someone would point me out to it. Thanks, --- Yaniv ___ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user ___ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo4j] [SPAM] Re: Datetimes in Neo4j REST Server
Perhaps I'm missing something here, but since Neo4j does not support dates,
then surely neither should the main REST API? If a users application decided
to store dates in strings, then their client code would also already need to
deal with the dates as strings, regardless of whether the client talked to
the database direct, or through REST. Likewise if they used long timestamps.
IMHO it is an application level issue.
My vote is to keep the REST API as close as possible to the core Neo4j. If
dates are added to the core, then add them to the REST API. Until then,
surely this is an application level issue...
On Thu, Nov 25, 2010 at 8:23 AM, Max De Marzi Jr. maxdema...@gmail.comwrote:
I was thinking about this...Neo4j doesn't really do Dates. It's Java
Primitives or Strings.
So how about we just establish a convention?
Something like:
Any field ending in date, time, _at, or _on is assumed to be a
date (in Unix Epoch milliseconds) and will be converted (from string,
int, long, float, double) into whatever the idiomatic way for handling
dates is (in the language of the library being used).
On Wed, Nov 24, 2010 at 2:15 AM, Mattias Persson
matt...@neotechnology.com wrote:
Neo4j REST/Server handles array values:
{ array-property: [10, 321, 45] }
2010/11/24 Max De Marzi Jr. maxdema...@gmail.com
BSON seems to have an Array type as well.
http://bsonspec.org/#/specification
On Tue, Nov 23, 2010 at 7:40 PM, Javier de la Rosa ver...@gmail.com
wrote:
IMHO, the data types that are not supported by the Neo4j REST API are
Date and Binary data. So it could be a solution add a Neo4j special
dictionary for these cases:
{
address:
{
streetAddress: 21 2nd Street,
city: New York,
state: NY,
postalCode: 10021,
birthdate: {
__ntype__: /Date(36779659600.0)/, # Timestamp in
Javascript supports BC dates
__nval__: 1971-02-03T00:00:00 # ISO Format also
supports BC dates
}
},
}
On the other hand, I don't know how Neo4j handles Arrays and Objects
in order to put them like values in properties when they came from a
REST client. It Neo4j doesn't handle this, then it's not a problem to
have some special dics for dates.
All of this come from the limitations on JSON by itself. It's more
usual of what we think to use a domain specific implementation for the
JSON interchange. For example, Cassandra uses JSON2SStable to
import/export data, and mongoDB created BSON [1] to support Date and
binary data.
Best regards.
[1] http://bsonspec.org/
On Tue, Nov 23, 2010 at 19:02, Max De Marzi Jr. maxdema...@gmail.com
wrote:
What about:
data: {name : NeoS::Max}, age: {NeoI::31 }
data: {name : NeoS[]::Max,Javier,Peter}, age:
{NeoI[]::31,29,33 }
On Tue, Nov 23, 2010 at 4:59 PM, Rick Bullotta
rick.bullo...@burningskysoftware.com wrote:
FWIW, we store all dates as milliseconds relative to UTC, and pass
them
around in that format. We identify the data types of
fields/properties
in
separate metadata structures embedded in the response, making the
returned
content easily parsable and interpretable by relatively dumb
clients.
-Original Message-
From: user-boun...@lists.neo4j.org [mailto:
user-boun...@lists.neo4j.org] On
Behalf Of Javier de la Rosa
Sent: Tuesday, November 23, 2010 4:26 PM
To: Neo4j user discussions
Subject: [SPAM] Re: [Neo4j] Datetimes in Neo4j REST Server
On Tue, Nov 23, 2010 at 16:05, Peter Neubauer
peter.neuba...@neotechnology.com wrote:
Jim, what do you say about that? How type safe can we make the REST
API? At least I think this warrants an issue over at
https://trac.neo4j.org/ticket/286 for this.
Thank you Peter and Max for the quick response. It would be great to
have well defined data types in the REST server.
I hope the solution also works in order to talk to the server what
types are sent to it, because now we have no way to create Date or
List objects like properties in nodes or relationships trhough the
REST API.
It's not easy manage with Dates and objects in JSON. The proposal in
https://trac.neo4j.org/ticket/286 adds some overhead although I
think
is a very good solution. However, there wouldn't be backwards
compatibility.
Best regards.
--
Javier de la Rosa
http://versae.es
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user
--
Javier
Re: [Neo4j] Modeling inheritance in Neo4J
Craig, I like the tag tree idea. Quite flexible indeed. Thanks! --- Yaniv On Thu, Nov 25, 2010 at 1:59 PM, Craig Taverner cr...@amanzi.com wrote: Another factor to consider is multiple inheritance, where you are grouping the people into overlapping groups. For example, you can have the users/non.users split, but also perhaps a man/woman split, and this results in four types. If you are concerned about having to restructure the graph when adding new types, then I would suggest using a tag approach. This means you forget about inheritance, keep all person nodes directly under people, and add tags to the person as and when you need to. There are two ways to add a tag: - Have a ref-tags-tag tree along side your ref-people-person tree, and then you can cross link individual tag nodes to person nodes as an when you want. This is very dynamic and easy to maintain. If your GUI allows users to add tags, you can support that also, by adding missing tags if needed. - Use lucene, by adding a tags string property to the person and indexing that. This allows for free-form tagging, but does make the whole thing less definitive. My preference, as usual with such things, is to build a graph for it :-) (ie. the tag tree). On Thu, Nov 25, 2010 at 12:49 PM, Yaniv Ben Yosef yani...@gmail.com wrote: Hi, I'm looking for best practices in modeling inheritance in Neo4J. Suppose I have a Person class. In the DB I naturally have a node for each person. I'm following the design guide, and created a PEOPLE subreference node, connected to all Person nodes (A and B in the diagram below) +--- A | REF -- PEOPLE --+ | +--- B Now suppose I introduce a User class, that extends Person. I thought about a couple of options: 1. I could just connect the user nodes to the PEOPLE node, but then it would be more difficult to traverse only users. 2. Adding another layer of sub-referencing +--- USERS +-- C | | REF -- PEOPLE --+ +-- D | +--- NONUSERS -+-- A | +-- B So there's the USERS node that is connected to all user nodes, and a NONUSERS node that is connected to all of the concrete Person nodes. This way the Person and User factories handle the connections to each subreference node. The downside of this is that as I introduce more types in the class hierarchy I need to start rewiring everything, which can be quite tedious at present and very costly in the long run. 3. Perhaps a better way is to avoid the NONUSERS node, keep the concrete People (A and B in this example) connected to the PEOPLE node [Option2]: +--- USERS +-- C | | REF -- PEOPLE --+ +-- D | +---+-- A | +-- B Of course, I'd use different relationship types so I can tell between people and and subreferences connected to PEOPLE. I'm sure these aren't the only ways, and there may be different ways to handle different cases. In any event, I'd appreciate your feedback, as well as any additional tips related to inheritance. Also, if there's any Neo4J guide for managing inheritance that I missed, it would be great if someone would point me out to it. Thanks, --- Yaniv ___ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user ___ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user ___ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo4j] [SPAM] Re: Datetimes in Neo4j REST Server
On Thu, Nov 25, 2010 at 07:11, Craig Taverner cr...@amanzi.com wrote: My vote is to keep the REST API as close as possible to the core Neo4j. If dates are added to the core, then add them to the REST API. Until then, surely this is an application level issue... +1. I wish the Date type were added soon to the Neo4j core. It woul be a good extra point in traversals. -- Javier de la Rosa http://versae.es ___ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo4j] [SPAM] Re: [SPAM] Re: Datetimes in Neo4j REST Server
+1. - Reply message - From: Javier de la Rosa ver...@gmail.com Date: Thu, Nov 25, 2010 10:58 am Subject: [SPAM] Re: [Neo4j] [SPAM] Re: Datetimes in Neo4j REST Server To: Neo4j user discussions user@lists.neo4j.org On Thu, Nov 25, 2010 at 07:11, Craig Taverner cr...@amanzi.com wrote: My vote is to keep the REST API as close as possible to the core Neo4j. If dates are added to the core, then add them to the REST API. Until then, surely this is an application level issue... +1. I wish the Date type were added soon to the Neo4j core. It woul be a good extra point in traversals. -- Javier de la Rosa http://versae.es ___ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user ___ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo4j] New IndexProvider not registering
2010/11/25 Peter Neubauer peter.neuba...@neotechnology.com Hi all, Craig and me thought of registering Neo4j-Spatial as a new IndexProvider, so you can set up a NodeIndex with all the geographic hints and setup you need, and then just index geometry nodes and ask spatial queries over it in order to make the component better usable, hopefully as easy as Lucene. Now, upon implementing https://github.com/neo4j/neo4j-spatial/blob/master/src/main/java/org/neo4j/gis/spatial/indexprovider/SpatialIndexProvider.java and registering it like https://github.com/neo4j/neo4j-spatial/blob/master/src/main/resources/META-INF/services/org.neo4j.kernel.KernelExtension , the test https://github.com/neo4j/neo4j-spatial/blob/master/src/test/java/org/neo4j/gis/spatial/IndexProviderTest.java is failing, saying that no index provider spatial was found. Anything wrong in the process? Sounds great, and be sure to express any difficulties/shortcomings with the API so that it can improved for these kinds of scenarios. It may be that you have to make the constructor public (I don't know in what way the service API uses reflection and all that). Also there's this assumption that an IndexProvider provides its own data source. The spatial index provider uses the graph itself (right?) so it could be a problem. Let me look at and fix that, and then document how that's done for such a scenario (hopefully tomorrow). Cheers, /peter neubauer GTalk: neubauer.peter Skype peter.neubauer Phone +46 704 106975 LinkedIn http://www.linkedin.com/in/neubauer Twitter http://twitter.com/peterneubauer http://www.neo4j.org - Your high performance graph database. http://www.thoughtmade.com - Scandinavia's coolest Bring-a-Thing party. ___ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user -- Mattias Persson, [matt...@neotechnology.com] Hacker, Neo Technology www.neotechnology.com ___ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo4j] Release 1.0.0.beta.22
Great stuff Andreas, we had a great evening in Barcelona yesterday, showing off the great work you, Ben and all the others are doing! Fantastic API and features! Craig and me are working on getting the Neo4j Spatial supported (at least the basic features) as a normal index provider in Neo4j. That would mean that you then in Neo4j.rb can directly ask not only text queries with Lucene but even spatial queries. Would be very cool to get that in, too :) Btw, what does everyone feel about REST vs. native protocols like RMI, Protobuffers, etc that can support a full Neo4j remote API for integration, with TX etc and would be optimized for driver development in other langs, minicing the Java core API capabilities very close? Any thoughts or preferences on one or the other? Does REST do a sufficiently good job for production use from other langs? What would you like to see in REST to get there - top 3 features? We are just trying to figure out the best way to expose and support the different Remote options ... Cheers, /peter neubauer GTalk: neubauer.peter Skype peter.neubauer Phone +46 704 106975 LinkedIn http://www.linkedin.com/in/neubauer Twitter http://twitter.com/peterneubauer http://www.neo4j.org - Your high performance graph database. http://www.thoughtmade.com - Scandinavia's coolest Bring-a-Thing party. On Thu, Nov 25, 2010 at 8:00 PM, Andreas Ronge andreas.ro...@gmail.com wrote: Hi I've just released 1.0.0.beta.22 The big news is that you can now use the rails console while the rails application is already running. I first tried to access neo4j remotely via RMI and DRb but there were to many problems doing that, so instead I simply create a read only neo4j db when needed. CHANGELOG * If a neo4j write instance is already running it will instead start a read only neo4j db instance. * Upgrade JARS to 1.2.M04 * Does not automatically start Neo4j when used in Rails. E.g. now you can type rails routes without the database starting. -- You received this message because you are subscribed to the Google Groups neo4jrb group. To post to this group, send email to neo4...@googlegroups.com. To unsubscribe from this group, send email to neo4jrb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/neo4jrb?hl=en. ___ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
