Tinkerpop 3: Custom DSLs, Traversal Strategies

[Dave]

Hi,

I did a lot of work around Graph Strategies in the M4-M6 releases but stopped due to it dramatically changing. I'm now just getting back into it and have some questions.  

We have a simple use case (prototype) around versioning. When we create a new vertex, edge or vertex property (Element) we add a "created" timestamp property. We have a custom traversal strategy that essentially manipulates the Gremlin traversal (specifically AddV, AddE, Property, steps etc.) buy appending the "created" property to the property set passed in at creation - almost identical to how PartitionStrategy does it with partitions. We add a "removed" timestamp when an element is deleted and replace the "Drop" step in the traversal with setting the "removed" property value. When a property value is updated we use VertexProperty functionality by created a new key/value pair and again assigning a "created" timestamp. This is all basic stuff and inserting/replacing the steps is hidden from the user (BTW, what happened to "~" for hiding properties?).

When querying, to be more expressive I would like to add a custom Gremlin step (both implicitly and explicitly) called "at"  that takes a timestamp to filter elements based on time. If the "at" step is not explicitly specified in the traversal the traversal strategy will insert it with the current timestamp to get currently active elements. For example:-

g.V().at(1234)       //  lets vertices active at time 1234 pass through 

I now see that the custom DSL section has been removed from GA docs and wondered if this is supported and how best to do it?   I did see Neo4jGraphStep and assume this is the best approach?  Also, I really don't need a custom DSL - I just need to add one custom step to the standard DSL.

I understand that I can probably represent the above using standard steps ("has" with conditions) but am using this as more of a learning exercise than anything else. So if there is a more elegant way to do it and I'm missing functionality please let me know. 

Lastly, I'm assuming that the basic graph API methods "addVertex", "addEdge" etc. are not affected by the traversal strategy and hence AddV, AddE steps etc. must be used?   

Thanks,

Dave

    

 

[Stephen Mallette]

Hi Dave, nice to have you back on TinkerPop3 talk.  Let's see if I can answer your questions:

BTW, what happened to "~" for hiding properties?).

"hiddens" are no longer for end users.  "hiddens" represent a vendor namespace and are only specified for their internal use.

 

When querying, to be more expressive I would like to add a custom Gremlin step (both implicitly and explicitly) called "at"  that takes a timestamp to filter elements based on time. If the "at" step is not explicitly specified in the traversal the traversal strategy will insert it with the current timestamp to get currently active elements. For example:-

g.V().at(1234)       //  lets vertices active at time 1234 pass through 

cool - this is a fairly common use case.  i'd like to think we could have something like this built into TP3 directly at some point.

 

I now see that the custom DSL section has been removed from GA docs and wondered if this is supported and how best to do it?   I did see Neo4jGraphStep and assume this is the best approach?  Also, I really don't need a custom DSL - I just need to add one custom step to the standard DSL.

Marko removed that section of the docs until it had been given more thought.  

 

I understand that I can probably represent the above using standard steps ("has" with conditions) but am using this as more of a learning exercise than anything else. So if there is a more elegant way to do it and I'm missing functionality please let me know. 

When possible you should use "standard steps".  Why? Because if you add your own steps, neither TinkerPop nor vendor TraversalStrategy implementations will be able to optimize them.  In the case of your at() step which is a form of filter, you would likely want a graph to take advantage of that if possible.  If you want to include at() in that DSL style don't use a custom Step, just use the existing HasStep to accomplish what you need under the covers.  In other words, just make at() a domain specific has().

 

Lastly, I'm assuming that the basic graph API methods "addVertex", "addEdge" etc. are not affected by the traversal strategy and hence AddV, AddE steps etc. must be used?   

correct - restrict your usage to a Traversal.

 

--
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/ee588d0e-18a5-4a32-b430-e47940384a26%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dave]

Hi Stephen,

I'm not quite sure how to implement an item in your post:-

"In the case of your at() step which is a form of filter, you would likely want a graph to take advantage of that if possible.  If you want to include at() in that DSL style don't use a custom Step, just use the existing HasStep to accomplish what you need under the covers.  In other words, just make at() a domain specific has()"

1) I assume I would generate a custom DSL that inherits from GraphTraversal to include the "at" step.

2) I write an "at" step that is really just a place holder i.e. its an empty step.

3) The traversal strategy replaces the "at" step with the standard "has" step. 

Am I understanding the implementation correctly?

Thanks,

Dave

[Stephen Mallette]

I meant:

1) I assume I would generate a custom DSL that inherits from GraphTraversal and add an "at" method

2) In your "at" method just have it add a HasStep to the traversal

[potera...@gmail.com]

Hi Stephen

That would mean a custom GraphTraversalSource should also be created in order to override the generateTraversal method which is supposed to return an instance of the custom GraphTraversal. Unfortunately inheriting the GraphTraversalSource doesn't make sense due to the private constructors and attributes. One would have to duplicate the GraphTraversalSource's code which is ugly!

Cheers,

Cosmin. 

[Stephen Mallette]

Yes - code duplication is ugly.  The DSL patterns still need some thought I believe - that's why Marko removed some discussion of them from the 3.0.0 documentation.  I just created this issue for tracking and discussion:

https://issues.apache.org/jira/browse/TINKERPOP3-786

Hopefully we can establish some recommended patterns in time for 3.1.0

[potera...@gmail.com]

Thanks Stephen!