gremlin-scala
gremlin-scala copied to clipboard
The issue of nested structures
@joan38 @mpollmeier I tested the nested classes on Neo4J and Titan none of them support any Map implementation for now. So we cannot have nested case classes in those DBs, the only one that I haven't test is OrientDB, BUT surprisingly OrientDB support container types which I think makes it a nice DB for our implementation, look at: http://orientdb.com/docs/2.0/orientdb.wiki/Types.html
I had some question about usage of OrientDB with GremlinScala which I asked in https://github.com/mpollmeier/gremlin-scala-examples/issues/8
But it's a little be strange that Tinkerpop team provided the TinkerGraph as the test bed for all of these if it has some functionality that others don't. The way that we handled the case classes here doesn't affect flat case classes and we are good with them. I hope DBs in future add these container types to their system.
But if these DBs don't want to support these collections, I think we can add two other functions that serialize the object into JSON, something like this:
val jack = Person("jack", Address(12345))
val v1 = gs.saveJson(jack)
val jack1 = v1.loadJson[Person]
I can do it in this weekend. We can serialize it in a string format. There are some problems with JSON obviously:
- We cannot easily provide indexing for it. There is hack for it (we can duplicate the keys that are going to be in index as a property and keep track of them)
- Getting specific property from the object then would be hard, we should cast it first and then get the value, which it needs a type safe traversal, for example something like this:
GremlinScala(graph).V.as("a")
.out.as("b")
.loadJson[Addreess].name.as("c")
I am not really sure about these, please let me know if you have any other idea or how much you think it's important. I think it's important to have DB interface that you just save your object in code into a DB and load it without any explicit conversion.
I tested the Nested Structures case in OrientDB and it's working like a charm.
I agree that it would be nice to provide this functionality, however as you already noted there are some rough edges when it comes to indexing and using them as properties, and this potentially has to be handled separately for each graph db. Feels like this discussion should happen on the Tinkerpop mailing list, what do you think?
that's good idea! I personally started to work with OrientDB for now which support collections. Let me know whenever you posted the question in Tinkerpop mailing list.
as discussed in chat: https://groups.google.com/forum/#!topic/gremlin-users/zfiwegX-1u8