TP3 gremlin-server, logic behind removing underscore prefixes

45 views
Skip to first unread message

Dmill

unread,
Mar 27, 2015, 12:32:16 PM3/27/15
to gremli...@googlegroups.com
Hey guys,

I've been migrating code over from TP2 to TP3 (Titan 0.9.0-M1 to be exact). I'm using cassandra+es via gremlin server.
I noticed that vertex and edge meta attributes (id, label, type, properties, inV, outV, etc.) used to to be prefixed with underscores but no longer have them. I was wondering if there was a reason behind this?

The reason I ask is that during the Object mapping of db entries (for non java languages, or php in my case) the element properties are often (almost systematically) accessible as properties of the object. In pseudo code:

var1 = VertexObject.property1;
var2 = VertexObject.property2;

This keeps things simple and has the advantage of not being as verbose as say : var1 = VertexObject.getProperty('property1');
The problem is that VetexObject.label should also be accessible which implies tha

Dmill

unread,
Mar 27, 2015, 12:42:44 PM3/27/15
to gremli...@googlegroups.com
Sorry sent as I was typing. Starting from the last sentence:
The problem is that VetexObject.label should also be accessible which implies that label should be a reserved word and not be used as an element property. Unfortunately, label and type for instance are quite popular as properties and restricting their use is.. well.. a bummer.
Even though this can be worked around it would imply that external libraries and/or frameworks that use the "standard" Object Mapping would need rewriting (too tedious).

So that's why I was wondering. I'm also curious to know if any non-java developers from the TP3 stack have an opinion on this.

Stephen Mallette

unread,
Mar 27, 2015, 1:11:08 PM3/27/15
to gremli...@googlegroups.com
This only changed between TP2 and TP3 as best I can tell.  I assume that's the change you are referring to.  I can't see where we ever had underscores in TP3.  I'm not sure if there was a reason for the change except that there is no longer any naming conflicts on those fields, because GraphSON for an edge in TP2 looked like this:

{
  "weight": 0.5,
  "_id": "7",
  "_type": "edge",
  "_outV": "1",
  "_inV": "2",
  "_label": "knows"
}

where the user data (e.g. weight) were at the same level as the surrounding first class citizen properties (e.g. label, type, etc.).  In TP3, user data has been isolated into a "properties" key as follows:

{
  "inV": 2,
  "inVLabel": "person",
  "outVLabel": "person",
  "id": 7,
  "label": "knows",
  "type": "edge",
  "outV": 1,
  "properties": {
    "weight": 0.5
  }
}

thus no possible conflict with the first class citizens.  



--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/gremlin-users/8f198781-1e94-40c0-8ad1-1386787d6651%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Dylan Millikin

unread,
Mar 27, 2015, 2:01:29 PM3/27/15
to gremli...@googlegroups.com
Thanks for the response Stephen!

Yes I meant since TP2. Ok that makes sense. 
The problem I guess is that in existing libraries and frameworks (php at least) that provide a number of features around predefined database objects, we're expected to make properties and first class citizens reside on the same level (at least virtually). Thus once we get the data from the database we flatten it into an object and re-introduce the naming conflicts.

I think this way of working isn't exclusive to php libraries but that would have to be confirmed by other developers? 

It isn't really a blocking matter as these "reserved" first class citizen keys can be worked around but depending on the feedback it might be worth thinking about.

Best,
Dylan.

--
You received this message because you are subscribed to a topic in the Google Groups "Gremlin-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/gremlin-users/phprb20ys1s/unsubscribe.
To unsubscribe from this group and all its topics, send an email to gremlin-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gremlin-users/CAA-H43-Gw8MC0fCxrV%3DvEUkxbaEn0aMYK%2B1ST%3DBXHup7KWda%2BQ%40mail.gmail.com.

Stephen Mallette

unread,
Mar 27, 2015, 2:10:49 PM3/27/15
to gremli...@googlegroups.com
I see what you're trying to do.  There is actually more reason for the new imposed hierarchy: Multi/Meta Property serialization.  I showed you Edge output - vertex is a bit crazier and i think representing it close to the actual Java object representation might be the best way.  You may want to take a look at the GraphSON section of the docs a bit to see what that looks like:




Dylan Millikin

unread,
Mar 27, 2015, 2:34:34 PM3/27/15
to gremli...@googlegroups.com
Yeah thanks, I had a look at that. I like this better than how it was before to be honest. 
It's just getting tricky migrating over, most of these systems were thought out with rdbms in mind, but since there's no schema it complicates things a lot. The underscore prefixes used in TP2 were unwillingly a very practical solution. We'll just have to adjust and work around it now :).



Reply all
Reply to author
Forward
0 new messages