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/26 19:52:35 UTC
[TinkerPop3] 3.1.0 Update to Mutations via GraphTraversal
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
Re: [TinkerPop3] 3.1.0 Update to Mutations via GraphTraversal
Posted by Stephen Mallette <sp...@gmail.com>.
Hi David, I appreciate your concerns. Generally speaking, I think we're
being quite mindful of breaking code during upgrades, especially when
compared with our pre-Apache Software Foundation days. I think that the
committers are all considering the impact a change will have to the
community and processes (like the "breaking" label in JIRA) are emerging to
help make upgrades for vendors as simple as possible. So - I think the goal
of committers is in synch with your concerns - let me try to address your
individual points below:
> Have we made it easy for adopters to understand how we might
> break their implementations without them having to plow through every Jira
> or mailing list post? That may be obvious to people sleeping and breathing
> the project, but not to others.
>
The addition of the "breaking" label was the first line of defense for
this. On this mailing list, we've discussed putting the JIRA tickets for
a release into the CHANGELOG on release and organizing those tickets in the
CHANGELOG more clearly to reflect that they are ones core interface
developers should watch (see item 3 .iii):
https://github.com/apache/incubator-tinkerpop/blob/master/RELEASE.asciidoc
I was thinking they would then visit the JIRA tickets for the detailed
notes on what changed and what could be a problem. I was further thinking
that a comment (presumably the last one) of a "breaking" ticket would end
up summarizing the stuff the dev would have to look out for - see this
"breaking" ticket as an example:
https://issues.apache.org/jira/browse/TINKERPOP3-805?focusedCommentId=14700198&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14700198
How do folks feel about that approach for documenting the places where
vendors could have problems when they bump their pom version? Do we need
more than that?
> I see Jiras like “gremlin virtual machine” and wonder what that really
> means. Will this enable vendors and users? Will it broaden the platform
> support of TP3 without breaking current implementations? Will it allow
> many graph platforms to embrace a very similar version of TP so there is an
> illusion of standardization? Are vendors broken or at a disadvantage if
> they don’t embrace the “gremlin virtual machine” concept immediately? This
> is just one Jira in the hopper. What about the rest?
>
My guess is that you are just using "gremlin virtual machine" as an example
- so I won't respond to the specifics of that question other than to say
that this ticket is not scheduled for any version at this point - it is
just a proposal for more discussion (note that the "Fix Versions" field is
not set):
https://issues.apache.org/jira/browse/TINKERPOP3-813
If you would like greater clarity on those items, please ask away on JIRA
or post your questions to the list by replying to Marko's original thread.
> TP users face similar challenges. They just suffered through massive
> changes between 2.x and TP3 GA. Maybe their lives are ultimately better,
> but if they are still waiting on their graph packages to be updated to some
> version of TP, do they even know where to start with TP3 when new
> functions are already deprecated?
Perhaps there will be some disagreement, but I don't see deprecation as a
hard thing for folks to deal with. If methods were simply removed and it
broke everyone's code when a release was issued, I'd call that a big
problem, but a @Deprecated method with clear javadocs on when it was
replaced and what you should do to make things right doesn't seem that
disruptive. It is only on actual removal of the deprecated method that
folks will experience pain. Have we completely thought through how
"removal" will work? No (as there are no plans I'm aware of for removing
any for the foreseeable future). If you'd like to suggest some procedures
for what we should do when we remove and how we alert the community to the
issue, please feel free to offer your ideas.
> All the old, misleading examples of
> Gremlin out on the mailing list and internet aside, are we asking users to
> digest even more changes immediately to use Gremlin ?
My vote would be to not remove any deprecated methods any time soon, so I
would fully expect all existing TP3 examples for 3.0.x to continue to work
for some time (i.e. 3.1.x 3.2.x, etc).
> Is GremlinDocs up to
> date with 3.0 GA yet? (http://gremlindocs.spmallette.documentup.com/) ?
>
GremlinDocs is my personal project. I've not brought it up to TP3 yet.
I'm still trying to sort out what I want it to look like. TP3 docs are
very different from TP2 and I'd like GremlinDocs to be a good companion to
them (not repetitive information). It will likely not have the same
style/content as before, as the "steps" section of TP3 docs largely matches
the pattern GremlinDocs originally set - not much point to recreating
that. I'm open to getting help on it from anyone who wants to contribute
some time.
> A focus on more new function to the expense of a full on focus around
> enablement of vendors, languages, platforms and users, at least for the
> moment, seems misdirected. What focus are we getting with 3.1 and 3.2 ?
>
I can't say that I agree that our efforts since GA released are
misdirected. There hasn't been a "full on focus around enablement of
vendors, languages, platforms and users" which sounds like a way of saying
"write more docs, blog posts, tutorials, etc", but we have fixed bugs, made
optimizations, filled gaps in the documentation, and, yes, added new
features in what I believe is a sane way that protects backward
compatibility with previous versions. If you want to challenge "sane", I
think you have to get deeper into JIRA. What do you need to look at to
know what's coming? Filter on the Fix Version field for 3.0.1 and 3.1.0
and you'll see what's coming up. There's nothing secretive about what's
being prioritized for a release and we are open to opinions.
Speaking specifically for BlueMix, I think it is worth your while to setup
an automated build of BlueMix against the two primary branches of
development in TP3 (tp30 and master). Check for new commits on those
branches and build bluemix against that to see what happens. You'll know
quite early if something is broken and we'll be happy to help you solve the
problem when/if that happens. If TP3 changes are breaking you all the
time, we'll need to have some discussions about that issue.
Even before TinkerPop entered incubation, I think we always worked really
well with vendors. TinkerPop is happy to have BlueMix as one of those
vendors and I think that you'll find that these "new features" for these
slated versions are not as deadly to your development cycles or to user
adoptions as you might think.
>
> On Mon, Aug 31, 2015 at 10:17 AM, Kelvin Lawrence <
> kelvin.r.lawrence@gmail.com> wrote:
>
> > Thanks for the replies guys. I think I may have been confused by the
> >> related Jira text that Marko posted on this topic. I read it as these
> >> changes would be hard for Titan to implement and therefore I inferred
> that
> >> these were quite breaking changes. After reading Marko's reply here I
> was
> >> having trouble reconciling that with what I thought I had read in the
> Jira.
> >> Having read the Jira text again this morning I guess Marko was probably
> >> saying he only did the changes that would *not* be hard for Titan to
> do. In
> >> that case sorry for my confusion!
> >>
> >
> > Kelvin
> >
>
Re: [TinkerPop3] 3.1.0 Update to Mutations via GraphTraversal
Posted by David Robinson <dr...@gmail.com>.
After reading through this exchange, I am uncomfortable around the topics
of vendor and user enablement with TinkerPop and with the planned changes
through 3.2.
If TinkerPop were a project unto itself, then I guess changes could be
plunked into the code base as fast as they could be added.
However, it is my impression that TinkerPop is most often encountered
through vendor products, open source and custom graph implementations, that
have embraced TP as an interface. This includes Gremlin as the query
language.
If it is “vendor” implementations (open source and custom too) that drive
TP adoption, what version do we recommended vendors implement if the TP
landscape continues to change quickly?
Do we think vendors have had time to catch up to TP 3.0 GA? It is my
impression that they have not. What else is planned in 3.1 and 3.2 that
will disrupt a vendor’s ability to pick a specific TP version with
confidence? Have we made it easy for adopters to understand how we might
break their implementations without them having to plow through every Jira
or mailing list post? That may be obvious to people sleeping and breathing
the project, but not to others.
Stephen’s response came the closest to addressing the heart of the issue
but still doesn’t feel satisfactory:
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.
It is rarely free. There are always test cases at a minimum.
I see Jiras like “gremlin virtual machine” and wonder what that really
means. Will this enable vendors and users? Will it broaden the platform
support of TP3 without breaking current implementations? Will it allow
many graph platforms to embrace a very similar version of TP so there is an
illusion of standardization? Are vendors broken or at a disadvantage if
they don’t embrace the “gremlin virtual machine” concept immediately? This
is just one Jira in the hopper. What about the rest?
TP users face similar challenges. They just suffered through massive
changes between 2.x and TP3 GA. Maybe their lives are ultimately better,
but if they are still waiting on their graph packages to be updated to some
version of TP, do they even know where to start with TP3 when new
functions are already deprecated? All the old, misleading examples of
Gremlin out on the mailing list and internet aside, are we asking users to
digest even more changes immediately to use Gremlin ? Is GremlinDocs up to
date with 3.0 GA yet? (http://gremlindocs.spmallette.documentup.com/) ?
The private Jira review that was held should have been public. It might
not have addressed any of the concerns here, but it might have helped.
A focus on more new function to the expense of a full on focus around
enablement of vendors, languages, platforms and users, at least for the
moment, seems misdirected. What focus are we getting with 3.1 and 3.2 ?
On Mon, Aug 31, 2015 at 10:17 AM, Kelvin Lawrence <
kelvin.r.lawrence@gmail.com> wrote:
> Thanks for the replies guys. I think I may have been confused by the
>> related Jira text that Marko posted on this topic. I read it as these
>> changes would be hard for Titan to implement and therefore I inferred that
>> these were quite breaking changes. After reading Marko's reply here I was
>> having trouble reconciling that with what I thought I had read in the Jira.
>> Having read the Jira text again this morning I guess Marko was probably
>> saying he only did the changes that would *not* be hard for Titan to do. In
>> that case sorry for my confusion!
>>
>
> Kelvin
>
Re: [TinkerPop3] 3.1.0 Update to Mutations via GraphTraversal
Posted by Kelvin Lawrence <ke...@gmail.com>.
>
> Thanks for the replies guys. I think I may have been confused by the
> related Jira text that Marko posted on this topic. I read it as these
> changes would be hard for Titan to implement and therefore I inferred that
> these were quite breaking changes. After reading Marko's reply here I was
> having trouble reconciling that with what I thought I had read in the Jira.
> Having read the Jira text again this morning I guess Marko was probably
> saying he only did the changes that would *not* be hard for Titan to do. In
> that case sorry for my confusion!
>
Kelvin
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.
>
Re: [TinkerPop] [TinkerPop3] 3.1.0 Update to Mutations via GraphTraversal
Posted by Marko Rodriguez <ok...@gmail.com>.
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] Re: [TinkerPop3] 3.1.0 Update to Mutations via GraphTraversal
Posted by Marko Rodriguez <ok...@gmail.com>.
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.