You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by Marko Rodriguez <ok...@gmail.com> on 2015/08/28 01:23:37 UTC
Re: [TinkerPop] [TinkerPop3] 3.1.0 Update to Mutations via GraphTraversal
Hey,
Let me add one caveat. If you are a Gremlin language vendor then no release will be fully "backwards compatible." Meaning, you can't just bump your pom.xml and be good. Why? We are constantly adding to the ProcessTestSuite so your language's test suite will have to be updated with the new tests with each release. Moreover, these test additions are not bound to "only the 3.x.0"-lines. There will be new tests (most definitely) with every stable release. And yes, I hate having to update Gremlin-Groovy with every test addition -- it is a mindless boring task.
Hope that is clear,
Marko.
http://markorodriguez.com
On Aug 27, 2015, at 5:00 PM, Marko Rodriguez <ok...@gmail.com> wrote:
> Hello,
>
>> Given that Tinkerpop 3.0 GA is still a fairly recent event, what are your thoughts on maintenance of that codebase moving forward?
>
> The plan is this:
>
> 3.0.z non-breaking changes. optimizations and bug fixes.
> 3.z.0 deprecated changes.
>
>> Specifically, I worry that if a point release soon after GA effectively deprecates many of the just released features that there is a real risk that Tinkerpop can not fully become the de-facto standard it is well on the road to becoming because it is too much of a moving target for developers to standardize on.
>
> The @Deprecated methods in GraphTraversal can still be used. They are simply deprecated. How long does deprecation last? We haven't thought of that. I suspect we will Annotate the method with a "will be removed by 3.4.0"-style message. Maybe not. Maybe just leave them there for all of the TP3 line.
>
>> I guess I had hoped that the rate and pace of change would slow down a bit post 3.0 GA to give folks a chance to catch up (the delta from Tinkerpop 2.0 being so substantial). Some of what you are describing here in many ways I think amounts to a 4.0 rather than a 3.1 update as it significantly changes many of the features that only just came out.
>
> The mutation updates are pretty trivial. These are not big changes at all. In fact, the @Deprecated methods simply call the new methods.
>
> https://github.com/apache/incubator-tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal.java#L678-L718
>
> AND
>
> https://github.com/apache/incubator-tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal.java#L646-L654
>
>> For example we just stood up a "graph as a service" implementation running on IBM's Bluemix and it will take non trivial amounts of work to migrate that from where it is today (supporting Tinkerpop 3.0) to supporting these new Tinkerpop 3.1 features that you are describing.
>
> You can support them when you like as TinkerPop 3.1 is backwards compatible with 3.0. Again, @Deprecate simply means these methods are not the best way to do things, but you can do it like that if you wish.
>
>> Have you guys given any thought to having a stable codebase (3.0) and an experimental codebase that you can roll all the new stuff out into and that would eventually end up becoming Tinkerpop 4.0? This would give vendors the chance to write code that is Tinkerpop 3.0 compliant and not have to keep changing it significantly to keep up with Tinkerpop point releases.
>
> We have not thought about TinkerPop 4.0 at all. Perhaps people have ideas for what that looks like.. ?
>
> HTH,
> Marko.
>
> http://markorodriguez.com
>
>
>>
>> On Wednesday, August 26, 2015 at 12:52:40 PM UTC-5, Marko A. Rodriguez wrote:
>> Hello,
>>
>> TinkerPop 3.0.0 released with the following mutation steps:
>>
>> addV()
>> addOutE()
>> addInE()
>> property()
>>
>> Their implementation and use via the GraphTraversal DSL was clunky and awkward. Someone, sometime ago (I wish I remembered his name. A true hero in my eyes), said: "How can I dynamically determine property values, edge labels, etc.?" That man, for whom I will forever be indebted to, lead me to realize "EVERYTHING IN GREMLIN IS A TRAVERSAL. There are no primitives…traversals within traversals is all there is. Except, one 'special traversal' called constant(x)." This realization was manifested in the AddXXXSteps and now you can do this:
>>
>> gremlin> g = TinkerFactory.createModern().traversal()
>> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
>> gremlin> g.V().as('a').outE('created').as('b').inV().
>> addE('createdBy').to('a').property('weight',select('b').values('weight'))
>> ==>e[12][3-createdBy->1]
>> ==>e[13][5-createdBy->4]
>> ==>e[14][3-createdBy->4]
>> ==>e[15][3-createdBy->6]
>> gremlin> g.E().hasLabel('createdBy').valueMap()
>> ==>[weight:0.4]
>> ==>[weight:1.0]
>> ==>[weight:0.4]
>> ==>[weight:0.2]
>> gremlin> g.V().property('friendWeight',bothE('knows').values('weight').sum())
>> ==>v[1]
>> ==>v[2]
>> ==>v[3]
>> ==>v[4]
>> ==>v[5]
>> ==>v[6]
>> gremlin> g.V().valueMap()
>> ==>[friendWeight:[1.5], name:[marko], age:[29]]
>> ==>[friendWeight:[0.5], name:[vadas], age:[27]]
>> ==>[friendWeight:[0.0], name:[lop], lang:[java]]
>> ==>[friendWeight:[1.0], name:[josh], age:[32]]
>> ==>[friendWeight:[0.0], name:[ripple], lang:[java]]
>> ==>[friendWeight:[0.0], name:[peter], age:[35]]
>> gremlin> g.V().as('a').addV('animal').property('name', select('a').values('name').map{it.get() + "'s pet"})
>> ==>v[22]
>> ==>v[24]
>> ==>v[26]
>> ==>v[28]
>> ==>v[30]
>> ==>v[32]
>> gremlin> g.V().hasLabel('animal').valueMap()
>> ==>[name:[peter's pet]]
>> ==>[name:[marko's pet]]
>> ==>[name:[vadas's pet]]
>> ==>[name:[lop's pet]]
>> ==>[name:[josh's pet]]
>> ==>[name:[ripple's pet]]
>> gremlin>
>> gremlin>
>> gremlin> g.V().match(
>> __.as('a').out('knows').as('b'),
>> __.as('a').out('created').as('c'),
>> __.as('b').out('created').as('c')).
>> addE('friendlyCollaborator').from('a').to('b').
>> property('project',select('c').values('name'))
>> ==>e[34][1-friendlyCollaborator->4]
>> gremlin> g.E().hasLabel('friendlyCollaborator').valueMap()
>> ==>[project:lop]
>> gremlin>
>>
>>
>> The 3.1.0-SNAPSHOT docs have been updated:
>>
>> http://tinkerpop.incubator.apache.org/docs/3.1.0-SNAPSHOT/#addedge-step
>> http://tinkerpop.incubator.apache.org/docs/3.1.0-SNAPSHOT/#addvertex-step
>> http://tinkerpop.incubator.apache.org/docs/3.1.0-SNAPSHOT/#addproperty-step
>>
>> NOTE: This is backwards compatible with 3.0.0. However, we have deprecated a few methods in GraphTraversal.
>>
>> Finally, we have a really cool class Parameters which we can, in theory, apply to every step for dynamic parameterization of a step. Check it:
>> https://github.com/apache/incubator-tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/util/Parameters.java
>>
>> You can see it in action here:
>> https://github.com/apache/incubator-tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/map/AddEdgeStep.java#L88-L92
>>
>> Again, in theory, we could support this in the future:
>>
>> g.V().outE().as('a')……out(select('a').label())
>>
>> Gnarly. However, for now, we will keep it simple and only allow such parameterization in the AddXXXSteps (and the current by() modulators -- which are related in an interesting way).
>>
>> Enjoy,
>> Marko.
>>
>> http://markorodriguez.com
>>
>>
>> --
>> 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-users+unsubscribe@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/msgid/gremlin-users/afdcb1ac-d4be-4671-8fa2-29619b50ee20%40googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
Re: [TinkerPop] [TinkerPop3] 3.1.0 Update to Mutations via GraphTraversal
Posted by Stephen Mallette <sp...@gmail.com>.
I'll just add a tiny bit to what marko wrote....
> For example we just stood up a "graph as a service" implementation running
> on IBM's Bluemix and it will take non trivial amounts of work to migrate
> that from where it is today (supporting Tinkerpop 3.0) to supporting these
> new Tinkerpop 3.1 features that you are describing.
>
>
> You can support them when you like as TinkerPop 3.1 is backwards
> compatible with 3.0. Again, @Deprecate simply means these methods are not
> the best way to do things, but you can do it like that if you wish.
>
>
I think that a lot of times changes shouldn't cost much to people
implementing the core API. "New Features" don't always mean new work at
that level - they could just be new features to end users which you get for
free by implementing the core interfaces.
Developers working with the core APIs should watch for the "breaking" label
in JIRA for areas to pay special attention to on a new version. "breaking"
does not always mean that your implementation will fall to pieces when you
bump to the new version. It's more of a warning/hint. For example, in
3.0.1 this issue is a "breaking" change:
https://issues.apache.org/jira/browse/TINKERPOP3-690
but all I did was rename a test in the test suite. So the only trouble
implementation developers would have is a failure in their test code IF
they happened to use the @OptOut annotation for that specific test (in
which case they'd need to fix the name to match the new name). Pretty low
risk of that happening and if it did happen....a minor adjustment to get it
working again, especially with the notes in the JIRA ticket for why
something is "breaking".
We'll keep trying to make version bumps as seamless as we can for everyone.
On Thu, Aug 27, 2015 at 7:23 PM, Marko Rodriguez <ok...@gmail.com>
wrote:
> Hey,
>
> Let me add one caveat. If you are a* Gremlin language vendor* then no
> release will be fully "backwards compatible." Meaning, you can't just bump
> your pom.xml and be good. Why? We are constantly adding to the
> ProcessTestSuite so your language's test suite will have to be updated with
> the new tests with each release. Moreover, these test additions are not
> bound to "only the 3.x.0"-lines. There will be new tests (most definitely)
> with every stable release. And yes, I hate having to update Gremlin-Groovy
> with every test addition -- it is a mindless boring task.
>
> Hope that is clear,
> Marko.
>
> http://markorodriguez.com
>
> On Aug 27, 2015, at 5:00 PM, Marko Rodriguez <ok...@gmail.com> wrote:
>
> Hello,
>
> Given that Tinkerpop 3.0 GA is still a fairly recent event, what are your
> thoughts on maintenance of that codebase moving forward?
>
>
> The plan is this:
>
> 3.0.z non-breaking changes. optimizations and bug fixes.
> 3.z.0 deprecated changes.
>
> Specifically, I worry that if a point release soon after GA effectively
> deprecates many of the just released features that there is a real risk
> that Tinkerpop can not fully become the de-facto standard it is well on the
> road to becoming because it is too much of a moving target for developers
> to standardize on.
>
>
> The @Deprecated methods in GraphTraversal can still be used. They are
> simply deprecated. How long does deprecation last? We haven't thought of
> that. I suspect we will Annotate the method with a "will be removed by
> 3.4.0"-style message. Maybe not. Maybe just leave them there for all of the
> TP3 line.
>
> I guess I had hoped that the rate and pace of change would slow down a bit
> post 3.0 GA to give folks a chance to catch up (the delta from Tinkerpop
> 2.0 being so substantial). Some of what you are describing here in many
> ways I think amounts to a 4.0 rather than a 3.1 update as it significantly
> changes many of the features that only just came out.
>
>
> The mutation updates are pretty trivial. These are not big changes at all.
> In fact, the @Deprecated methods simply call the new methods.
>
>
> https://github.com/apache/incubator-tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal.java#L678-L718
>
> AND
>
>
> https://github.com/apache/incubator-tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal.java#L646-L654
>
> For example we just stood up a "graph as a service" implementation running
> on IBM's Bluemix and it will take non trivial amounts of work to migrate
> that from where it is today (supporting Tinkerpop 3.0) to supporting these
> new Tinkerpop 3.1 features that you are describing.
>
>
> You can support them when you like as TinkerPop 3.1 is backwards
> compatible with 3.0. Again, @Deprecate simply means these methods are not
> the best way to do things, but you can do it like that if you wish.
>
> Have you guys given any thought to having a stable codebase (3.0) and an
> experimental codebase that you can roll all the new stuff out into and that
> would eventually end up becoming Tinkerpop 4.0? This would give vendors the
> chance to write code that is Tinkerpop 3.0 compliant and not have to keep
> changing it significantly to keep up with Tinkerpop point releases.
>
>
> We have not thought about TinkerPop 4.0 at all. Perhaps people have ideas
> for what that looks like.. ?
>
> HTH,
> Marko.
>
> http://markorodriguez.com
>
>
>
> On Wednesday, August 26, 2015 at 12:52:40 PM UTC-5, Marko A. Rodriguez
> wrote:
>>
>> Hello,
>>
>> TinkerPop 3.0.0 released with the following mutation steps:
>>
>> addV()
>> addOutE()
>> addInE()
>> property()
>>
>>
>> Their implementation and use via the GraphTraversal DSL was clunky and
>> awkward. Someone, sometime ago (I wish I remembered his name. A true hero
>> in my eyes), said: "How can I dynamically determine property values, edge
>> labels, etc.?" That man, for whom I will forever be indebted to, lead me to
>> realize "EVERYTHING IN GREMLIN IS A TRAVERSAL. There are no
>> primitives…traversals within traversals is all there is. Except, one
>> 'special traversal' called constant(x)." This realization was manifested in
>> the AddXXXSteps and now you can do this:
>>
>> gremlin> g = TinkerFactory.createModern().traversal()
>> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
>> gremlin> g.V().as('a').outE('created').as('b').inV().
>>
>> addE('createdBy').to('a').property('weight',select('b').values('weight'))
>> ==>e[12][3-createdBy->1]
>> ==>e[13][5-createdBy->4]
>> ==>e[14][3-createdBy->4]
>> ==>e[15][3-createdBy->6]
>> gremlin> g.E().hasLabel('createdBy').valueMap()
>> ==>[weight:0.4]
>> ==>[weight:1.0]
>> ==>[weight:0.4]
>> ==>[weight:0.2]
>> gremlin>
>> g.V().property('friendWeight',bothE('knows').values('weight').sum())
>> ==>v[1]
>> ==>v[2]
>> ==>v[3]
>> ==>v[4]
>> ==>v[5]
>> ==>v[6]
>> gremlin> g.V().valueMap()
>> ==>[friendWeight:[1.5], name:[marko], age:[29]]
>> ==>[friendWeight:[0.5], name:[vadas], age:[27]]
>> ==>[friendWeight:[0.0], name:[lop], lang:[java]]
>> ==>[friendWeight:[1.0], name:[josh], age:[32]]
>> ==>[friendWeight:[0.0], name:[ripple], lang:[java]]
>> ==>[friendWeight:[0.0], name:[peter], age:[35]]
>> gremlin> g.V().as('a').addV('animal').property('name',
>> select('a').values('name').map{it.get() + "'s pet"})
>> ==>v[22]
>> ==>v[24]
>> ==>v[26]
>> ==>v[28]
>> ==>v[30]
>> ==>v[32]
>> gremlin> g.V().hasLabel('animal').valueMap()
>> ==>[name:[peter's pet]]
>> ==>[name:[marko's pet]]
>> ==>[name:[vadas's pet]]
>> ==>[name:[lop's pet]]
>> ==>[name:[josh's pet]]
>> ==>[name:[ripple's pet]]
>> gremlin>
>> gremlin>
>> gremlin> g.V().match(
>> __.as('a').out('knows').as('b'),
>> __.as('a').out('created').as('c'),
>> __.as('b').out('created').as('c')).
>> addE('friendlyCollaborator').from('a').to('b').
>> property('project',select('c').values('name'))
>> ==>e[34][1-friendlyCollaborator->4]
>> gremlin> g.E().hasLabel('friendlyCollaborator').valueMap()
>> ==>[project:lop]
>> gremlin>
>>
>>
>>
>> The 3.1.0-SNAPSHOT docs have been updated:
>>
>> http://tinkerpop.incubator.apache.org/docs/3.1.0-SNAPSHOT/#addedge-step
>> http://tinkerpop.incubator.apache.org/docs/3.1.0-SNAPSHOT/#addvertex-step
>>
>> http://tinkerpop.incubator.apache.org/docs/3.1.0-SNAPSHOT/#addproperty-step
>>
>> *NOTE: *This is backwards compatible with 3.0.0. However, we have
>> deprecated a few methods in GraphTraversal.
>>
>> Finally, we have a really cool class Parameters which we can, in theory,
>> apply to every step for dynamic parameterization of a step. Check it:
>>
>> https://github.com/apache/incubator-tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/util/Parameters.java
>>
>> You can see it in action here:
>>
>> https://github.com/apache/incubator-tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/map/AddEdgeStep.java#L88-L92
>>
>> Again, in theory, we could support this in the future:
>>
>> g.V().outE().as('a')……out(select('a').label())
>>
>>
>> Gnarly. However, for now, we will keep it simple and only allow such
>> parameterization in the AddXXXSteps (and the current by() modulators --
>> which are related in an interesting way).
>>
>> Enjoy,
>> Marko.
>>
>> http://markorodriguez.com
>>
>>
> --
> 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-users+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/gremlin-users/afdcb1ac-d4be-4671-8fa2-29619b50ee20%40googlegroups.com
> <https://groups.google.com/d/msgid/gremlin-users/afdcb1ac-d4be-4671-8fa2-29619b50ee20%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> 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-users+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/gremlin-users/918128E6-F623-4E67-B4B9-A4FF4D376CFE%40gmail.com
> <https://groups.google.com/d/msgid/gremlin-users/918128E6-F623-4E67-B4B9-A4FF4D376CFE%40gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>