Re: [TinkerPop3] No more select() -- do you mind?

[Ran Magen <rm...@gmail.com>]

Sounds good, though I think having to include every variation of the
possible fields selected will be a chore, and will probably cause buggy
queries that won't be easily spotted.
On יום ג׳, 30 ביוני 2015 at 01:15 Daniel Kuppitz <me...@gremlin.guru> wrote:

> Recently <https://issues.apache.org/jira/browse/TINKERPOP3-753> on the
> TinkerPop issue tracker we came to the conclusion that we should get rid of
> select() (not select() altogether, but the parameter-less overload). As
> select(...) becomes more powerful with every release, the parameter-less
> select() also becomes more and more expensive and we think you / the user
> should actually know what he/she wants to select, thus specifying the keys
> shouldn't be a problem.
>
> Initially I was worried about dynamically created traversals, where several
> methods may add a piece to the final traversal. But this still shouldn't be
> an issue, since you should know what you want to select in the end anyway.
> And even if not, you can keep track of the keys and ultimately do this:
>
> traversal.select(keys as String[]) // in Groovy
> traversal.select(keys.toArray(new String[keys.size()])) // in Java
>
>
> There are a few pitfalls though. For those who don't want to read the posts
> in the issue tracker:
>
> gremlin> g.V().match(
> gremlin>   __.as("v").outE().count().as("outD"),
> gremlin>   __.as("v").inE().count().as("inD")
> gremlin> ).select("v").by(valueMap()).
> gremlin>   select("name","age","outD","inD")
> ==>[name:[marko], age:[29], outD:3, inD:0]
> ==>[name:[vadas], age:[27], outD:0, inD:1]
> ==>[name:[josh], age:[32], outD:2, inD:1]
> ==>[name:[peter], age:[35], outD:1, inD:0]
>
>
> As you can see, we only got the person vertices; software vertices are
> missing. That's because software vertices don't have an age property. But
> since we know our graph schema very well, we can easily solve it:
>
> gremlin> g.V().match(
> gremlin>   __.as("v").outE().count().as("outD"),
> gremlin>   __.as("v").inE().count().as("inD")
> gremlin> ).select("v").by(valueMap())*.choose(select("age"),*
> gremlin>   select("name","age","outD","inD"),
> gremlin>   *select("name","lang","outD","inD"))*
> ==>[name:[marko], age:[29], outD:3, inD:0]
> ==>[name:[vadas], age:[27], outD:0, inD:1]
> *==>[name:[lop], lang:[java], outD:0, inD:3]*
> ==>[name:[josh], age:[32], outD:2, inD:1]
> *==>[name:[ripple], lang:[java], outD:0, inD:1]*
> ==>[name:[peter], age:[35], outD:1, inD:0]
>
>
> If you still have any objections, please speak them out loud now.
>
> Cheers,
> Daniel
>

Re: [TinkerPop3] No more select() -- do you mind?

[Ran Magen <rm...@gmail.com>]

Maybe make the fields optional? Or add some sugar-step or strategy to
automate the {{choose(select(field)...)}} business.
On יום ו׳, 3 ביולי 2015 at 03:32 Ran Magen <rm...@gmail.com> wrote:

> Sounds good, though I think having to include every variation of the
> possible fields selected will be a chore, and will probably cause buggy
> queries that won't be easily spotted.
> On יום ג׳, 30 ביוני 2015 at 01:15 Daniel Kuppitz <me...@gremlin.guru> wrote:
>
>> Recently <https://issues.apache.org/jira/browse/TINKERPOP3-753> on the
>> TinkerPop issue tracker we came to the conclusion that we should get rid
>> of
>> select() (not select() altogether, but the parameter-less overload). As
>> select(...) becomes more powerful with every release, the parameter-less
>> select() also becomes more and more expensive and we think you / the user
>> should actually know what he/she wants to select, thus specifying the keys
>> shouldn't be a problem.
>>
>> Initially I was worried about dynamically created traversals, where
>> several
>> methods may add a piece to the final traversal. But this still shouldn't
>> be
>> an issue, since you should know what you want to select in the end anyway.
>> And even if not, you can keep track of the keys and ultimately do this:
>>
>> traversal.select(keys as String[]) // in Groovy
>> traversal.select(keys.toArray(new String[keys.size()])) // in Java
>>
>>
>> There are a few pitfalls though. For those who don't want to read the
>> posts
>> in the issue tracker:
>>
>> gremlin> g.V().match(
>> gremlin>   __.as("v").outE().count().as("outD"),
>> gremlin>   __.as("v").inE().count().as("inD")
>> gremlin> ).select("v").by(valueMap()).
>> gremlin>   select("name","age","outD","inD")
>> ==>[name:[marko], age:[29], outD:3, inD:0]
>> ==>[name:[vadas], age:[27], outD:0, inD:1]
>> ==>[name:[josh], age:[32], outD:2, inD:1]
>> ==>[name:[peter], age:[35], outD:1, inD:0]
>>
>>
>> As you can see, we only got the person vertices; software vertices are
>> missing. That's because software vertices don't have an age property. But
>> since we know our graph schema very well, we can easily solve it:
>>
>> gremlin> g.V().match(
>> gremlin>   __.as("v").outE().count().as("outD"),
>> gremlin>   __.as("v").inE().count().as("inD")
>> gremlin> ).select("v").by(valueMap())*.choose(select("age"),*
>> gremlin>   select("name","age","outD","inD"),
>> gremlin>   *select("name","lang","outD","inD"))*
>> ==>[name:[marko], age:[29], outD:3, inD:0]
>> ==>[name:[vadas], age:[27], outD:0, inD:1]
>> *==>[name:[lop], lang:[java], outD:0, inD:3]*
>> ==>[name:[josh], age:[32], outD:2, inD:1]
>> *==>[name:[ripple], lang:[java], outD:0, inD:1]*
>> ==>[name:[peter], age:[35], outD:1, inD:0]
>>
>>
>> If you still have any objections, please speak them out loud now.
>>
>> Cheers,
>> Daniel
>>
>