Hi everyone, I just gutted select(no arg). Kuppitz, Matt, and I have constantly run into issues with Scoping steps. The first problem was solved by https://issues.apache.org/jira/browse/TINKERPOP3-753. The second problem was with respect to select(no arg). Without the user specifying the keys they are selecting, SelectStep doesn't know if it requires path calculations or not and the user doesn't know the order in which by()-modulations will be applied. In short, lots of ambiguity. Now with the select-keys being explicit, the internal logic of SelectStep is much simpler.
https://raw.githubusercontent.com/apache/incubator-tinkerpop/f6a1a7d1ba20ed9a83227e11e49d3095ed02cbb4/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/map/SelectStep.java vs. https://raw.githubusercontent.com/apache/incubator-tinkerpop/43690dcd7e71429b00f7567474ea9353b8df4819/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/map/SelectStep.java Moreover, with TINKERPO3-753 complete, Scoping steps are no longer this complex web of "local"/"global" propagations (called recommendations). In fact, the GraphTraversal API no longer has Scope as a parameter for select() or where(). This should make things much easier for the user to understand as they "just select keys" and don't have to worry about if its a "local" key, a "global" key, etc. The code has been pushed and the docs have been updated: http://tinkerpop.incubator.apache.org/docs/3.0.0-SNAPSHOT/ Thanks, Marko. http://markorodriguez.com On Jun 29, 2015, at 4:15 PM, Daniel Kuppitz <[email protected]> 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
