Perhaps to add some strength to my argument I can give some indication
of our current graph's shape however.

Currently we have about 14 000 tables and about 220 000 columns in the
rdbms and it grows runtime as we support more and more vendors and
technologies. This is in the telco space.
100% of that is added, updated and deleted via the graph.

Maps makes this job way way easier.
If I were to use some graph implementation that does not have the map
interface natively I'd add some wrapper or util or something immediately

Data that comes in from etl processes or web frontends or wherever is
almost always already in a Map. Very very seldom do we work with varargs.
Not having a map interface forces clients to convert maps to varargs
meaning they'll add that wrapper/utility in their apps anyways.

The interface Sqlg added is `graph.addVertex(String label, Map<String,
Object> keyValues)`
The original varargs method is never invoked.


On 18/10/2016 16:05, Marko Rodriguez wrote:
> Hi,
> addV(Object…) was deprecated because it didn’t support Parameters (that is, 
> dynamic traversal based parametrization).
> g.V().has(’name’,’bob’).as(‘a’).
>   addV(‘person’).
>     property(‘name’,’stephen’).
>     property(‘status’,select(‘a’).by(’status’))
> We could support it in Object.., but then stuff looks weird:
> g.V().has(’name’,’bob’).as(‘a’).
>   addV(label,’person’,’name’,’stephen’,‘status’,select(‘a’).by(‘status’))
> You really don’t save that much typing and I think its best to be explicit so 
> traversals are more readable.
> To @pieter. In terms of Map arguments. We don’t have any steps/sources that 
> take Map arguments. I would prefer not to introduce a new data structure 
> especially when its so fuggly to create in Java.
> Thoughts?,
> Marko.
>> On Sep 28, 2016, at 1:03 PM, Pieter Martin <> wrote:
>> Well, I have to say I really like Map. In almost all of our code by the time 
>> we
>> are ready to create a vertex we have the properties already in a map. Data 
>> for
>> the most part are not captured by humans typing gremlin but by machines and
>> they store key value pairs in a Map.
>> Cheers
>> Pieter
>> Excerpts from Marko Rodriguez's message of September 28, 2016 7:18 :
>>> Hi,
>>> Right now we have:
>>>     addV().property(a,b).property(c,d,e,f)
>>> The second property() call creates a c=d vertex property with e=f 
>>> meta-property.
>>> We could do this:
>>>     addV(a,b,c,d).property(c).property(e,f)
>>> That is, addV() has a Object[]… arg. However, seems to be the same length 
>>> of characters. Though, without meta-properties:
>>>     addV().property(‘a’,b’).property(‘c’,’d’)
>>> …becomes:
>>>     addV(‘a’,’b’,’c’,’d’)
>>> I don’t really like Map as that is not a type we use anywhere else… Marko.
>>>> On Sep 28, 2016, at 10:41 AM, Stephen Mallette <> 
>>>> wrote:
>>>> Matthias re-opened that issue now looking to see g.addV(Map) given my
>>>> reasoning for closing.
>>>> On Tue, Sep 20, 2016 at 12:49 PM, Stephen Mallette <>
>>>> wrote:
>>>>> Anyone interested in seeing a Graph.addVertex(Map) overload?
>>>>> I don't imagine there would be any change to addV() in this case. I'm
>>>>> thinking that we wouldn't likely use this method internally and so it 
>>>>> would
>>>>> more be something for user convenience, in which case, it seems to
>>>>> encourage more use of the Graph API which we're typically trying to do 
>>>>> less
>>>>> of.

Reply via email to