Re: [TinkerPop] Frames: support for inheritance

[Marko Rodriguez]

Hi,

You can do this by adding your own annotations, but it could be possible for Frames to support it natively. Please make your email a ticket on the Frames issue tracker and we can discuss its development there.

Thank you for your thoughts,

Marko.

http://markorodriguez.com

On May 13, 2013, at 1:53 AM, gjdev <gerjon...@gmail.com> wrote:

We are looking at both Titan and the Tinkerpop stack for our NLP framework. I have been experimenting with Frames a bit. It looks like a very nice Object<->Graph mapper. However there is one feature that IMHO is sorely missing from it: support for inheritance. There are e few issues on github related to this (e.g. https://github.com/tinkerpop/frames/issues/15 and https://github.com/tinkerpop/frames/issues/25) but they only seem to partially address what I would consider proper support for inheritance.

What I would like to see is the ability to store a vertex-property in the graph based on the type of the VertexFrame, and also the ability to use that property-value when instantiating VertexFrame to make it have the correct interface(s) for the type. There are a couple of ways to do this. One possibility is a scheme that looks like (for a Person that can have Animal(s) of different types as pets:

@TypeField("type") // The field in which type-info is stored for animals.
//Since Animal does not have a TypeValue annotation, only subtypes of it can be instantiated (it's "abstract")
interface Animal { ... }
@TypeValue("dog") // So Dog-vertices have type=dog as property
interface Dog extends Animal { ... }
@TypeValue("cat")
interface Cat extends Animal { .... }
interface Person {
   @Adjacency(label = "pet") Iterable<? extends Animal> getPets();
   @Adjacency(label = "pet") void addPet(Animal animal);
}

Frames can then use the @TypeField and @TypeValue annotations when storing (serializing) objects into the graph. When deserializing (e.g. calling getPets) Frames is able to attach the correct interface(s) to a VertexFrame when interfaces are annotated with TypeField?TypeValues anotations. For interfaces that don't have TypeField/TypeValue interfaces nothing changes.

Comments? Is this something that others also see as useful for Frames? I'd be happy to invest some time in this, if the core developers can help me along, and are willing to accept patches that make this work.

--
You received this message because you are subscribed to the Google Groups "Gremlin-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gremlin-user...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[gjdev]

I have added issue https://github.com/tinkerpop/frames/issues/48

In response to your suggestion "You can do this by adding your own annotations": I don't think that's possible. I'd be happy to be proven wrong, but I don't see any customization possibilities in Frames that allow anything that resembles the suggested feature.

[Marko Rodriguez]

Hi,

I did not read your email fully so I don't know exactly what you are interested in doing, but I use a @Type annotation to store the Frame class names of the vertex on the vertex and thus, this allows me to deserialize them accordingly. Also, please see:

https://github.com/tinkerpop/frames/wiki/User-Defined-Annotations

If those don't help you, then when we get to your ticket we will see.

Thanks,

Marko.

http://markorodriguez.com

[gjdev]

I need Frames to be able to do both the serialisation and deserialisation to/from the correct type, much like what Hibernate and JPA are able to do with discriminator columns. Ultimately this boils down Frames instantiating a Dog, Cat, Fish or Crocodile when asked for an Animal with getVertex:

   Animal animal = graph().getVertex(null, Animal.class); //returns an instance of Dog or Cat or ...

I could duplicate all annotations in Frames with my own typed annotations (e.g. TypedAdjacency, TypedIncidence, etc.) to have something conceptually close (only when walking a graph). But it means the type-discriminator settings have to be repeated for every relation to a type (instead of only once per type). Not so nice. Plus it's still less powerful than having this in Frames.

It doesn't look like this is all that difficult to add to Frames, and we will need it if we are going to migrate to Titan/Blueprints. So I'll probably clone Frames anyway to add this feature. Would appreciate some feedback on the issue itself if you have the time.to read it.

Thanks

[Ondra Žižka]

We coded support for inheritance in the project Windup.
https://github.com/windup/windup/

HTH, Ondra