Re: [DISCUSS] Gryo 4.0
yes - javascript is the only one that is still on GraphSON as of 3.5.0. On Mon, Dec 27, 2021 at 6:54 PM David Bechberger wrote: > +1 on removing Gryo support > > It would be great to be able to simplify the serializer story. Is > Javascript the only language without GraphBinary support now? > > Dave > > On Mon, Dec 27, 2021 at 11:48 AM Stephen Mallette > wrote: > > > Just to clarify, I think you are suggesting the removal of the remaining > > deprecated GryoMessageSerializer instances thus removing Gryo as a > network > > serialization option at 3.6.0. We would retain Gryo as it pertains to > being > > a file storage format. > > > > We removed Gryo Lite for 3.6.0, so complete removal isn't too far around > > the corner. I dont think I have any problems with just doing it all for > > 3.6.0. It would continue to simplify the serialization story if it wasn't > > around. If we could then get Javascript on GraphBinary, we could then > > retire typed GraphSON versions and promote a simple GraphSON format for > > HTTP (like GraphSON 1.0). > > > > On Mon, Dec 27, 2021 at 7:56 AM Divij Vaidya > > wrote: > > > > > I agree about sun setting Gryo perhaps starting with the 3.6.x release. > > > > > > The reasons for removing it from the code base are as follows: > > > 1. Gryo serilization of properties is not consistent with the > GraphBinary > > > or Graphson. As an example, Gryo tries to fetch the label of the parent > > > element when serializing a property whereas other serializers only > > provide > > > the ID of the parent element. > > > 2. GraphBinary is a direct replacement with binary serialization > support > > > and better performance. GraphBinary support has also been expanded to > > > Python and is the default serializer starting 3.5.x release train. > > > > > > Divij Vaidya > > > > > > > > > > > > On Wed, Aug 26, 2020 at 10:28 AM Stephen Mallette < > spmalle...@gmail.com> > > > wrote: > > > > > > > I was just perusing JIRA a bit and came across an item to upgrade to > > Kryo > > > > 4.0 for a performance enhancement: > > > > > > > > https://issues.apache.org/jira/browse/TINKERPOP-2398 > > > > > > > > As I commented on that issue, which has not yet gotten a response, I > > > > believe that upgrading to Kryo 4.0 breaks binary compatibility with > > Kryo > > > > 3.0 which would mean we would probably need to stamp out Gryo 4.0 as > a > > > > result. > > > > > > > > I'm not sure I see the need to produce another version of Gryo as > we've > > > > deprecated it in Gremlin Server already and are pushing for wider use > > of > > > > GraphBinary as a replacement for Gryo and GraphSON for network > > > > serialization. I'm not sure where that leaves us with disk > > serialization > > > > but the limitation Gryo has in not working off the JVM hampers it a > bit > > > for > > > > what I think of as our current usage these days. > > > > > > > > I'm inclined to continue us on a path to full deprecation of Gryo, > even > > > for > > > > disk, in favor of GraphBinary, in which case, I don't think it's in > our > > > > interest to introduce Gryo 4.0. Does anyone have any thoughts on this > > > > topic? > > > > > > > > > >
Re: [DISCUSS] Gryo 4.0
+1 on removing Gryo support It would be great to be able to simplify the serializer story. Is Javascript the only language without GraphBinary support now? Dave On Mon, Dec 27, 2021 at 11:48 AM Stephen Mallette wrote: > Just to clarify, I think you are suggesting the removal of the remaining > deprecated GryoMessageSerializer instances thus removing Gryo as a network > serialization option at 3.6.0. We would retain Gryo as it pertains to being > a file storage format. > > We removed Gryo Lite for 3.6.0, so complete removal isn't too far around > the corner. I dont think I have any problems with just doing it all for > 3.6.0. It would continue to simplify the serialization story if it wasn't > around. If we could then get Javascript on GraphBinary, we could then > retire typed GraphSON versions and promote a simple GraphSON format for > HTTP (like GraphSON 1.0). > > On Mon, Dec 27, 2021 at 7:56 AM Divij Vaidya > wrote: > > > I agree about sun setting Gryo perhaps starting with the 3.6.x release. > > > > The reasons for removing it from the code base are as follows: > > 1. Gryo serilization of properties is not consistent with the GraphBinary > > or Graphson. As an example, Gryo tries to fetch the label of the parent > > element when serializing a property whereas other serializers only > provide > > the ID of the parent element. > > 2. GraphBinary is a direct replacement with binary serialization support > > and better performance. GraphBinary support has also been expanded to > > Python and is the default serializer starting 3.5.x release train. > > > > Divij Vaidya > > > > > > > > On Wed, Aug 26, 2020 at 10:28 AM Stephen Mallette > > wrote: > > > > > I was just perusing JIRA a bit and came across an item to upgrade to > Kryo > > > 4.0 for a performance enhancement: > > > > > > https://issues.apache.org/jira/browse/TINKERPOP-2398 > > > > > > As I commented on that issue, which has not yet gotten a response, I > > > believe that upgrading to Kryo 4.0 breaks binary compatibility with > Kryo > > > 3.0 which would mean we would probably need to stamp out Gryo 4.0 as a > > > result. > > > > > > I'm not sure I see the need to produce another version of Gryo as we've > > > deprecated it in Gremlin Server already and are pushing for wider use > of > > > GraphBinary as a replacement for Gryo and GraphSON for network > > > serialization. I'm not sure where that leaves us with disk > serialization > > > but the limitation Gryo has in not working off the JVM hampers it a bit > > for > > > what I think of as our current usage these days. > > > > > > I'm inclined to continue us on a path to full deprecation of Gryo, even > > for > > > disk, in favor of GraphBinary, in which case, I don't think it's in our > > > interest to introduce Gryo 4.0. Does anyone have any thoughts on this > > > topic? > > > > > >
[jira] [Closed] (TINKERPOP-2667) Allow fold() with addAll to work on Map
[
https://issues.apache.org/jira/browse/TINKERPOP-2667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Mallette closed TINKERPOP-2667.
---
Fix Version/s: 3.6.0
3.5.2
Resolution: Done
> Allow fold() with addAll to work on Map
> ---
>
> Key: TINKERPOP-2667
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2667
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.5.1
>Reporter: Stephen Mallette
>Assignee: Stephen Mallette
>Priority: Major
> Fix For: 3.6.0, 3.5.2
>
>
> The following bit of Gremlin should work as a method for merging {{Map}}:
> {code}
> gremlin> g.inject([a: 1],[b:2]).fold([:], addAll)
> ==>[a:1,b:2]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (TINKERPOP-2667) Allow fold() with addAll to work on Map
[
https://issues.apache.org/jira/browse/TINKERPOP-2667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17465887#comment-17465887
]
ASF GitHub Bot commented on TINKERPOP-2667:
---
spmallette merged pull request #1517:
URL: https://github.com/apache/tinkerpop/pull/1517
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@tinkerpop.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Allow fold() with addAll to work on Map
> ---
>
> Key: TINKERPOP-2667
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2667
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.5.1
>Reporter: Stephen Mallette
>Assignee: Stephen Mallette
>Priority: Major
>
> The following bit of Gremlin should work as a method for merging {{Map}}:
> {code}
> gremlin> g.inject([a: 1],[b:2]).fold([:], addAll)
> ==>[a:1,b:2]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (TINKERPOP-2666) Create an anonymizing Translator for logging traversals without user data
[
https://issues.apache.org/jira/browse/TINKERPOP-2666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Mallette closed TINKERPOP-2666.
---
Assignee: Stephen Mallette
Resolution: Done
> Create an anonymizing Translator for logging traversals without user data
> -
>
> Key: TINKERPOP-2666
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2666
> Project: TinkerPop
> Issue Type: Improvement
> Components: translator
>Affects Versions: 3.5.1
>Reporter: Mike Personick
>Assignee: Stephen Mallette
>Priority: Major
> Fix For: 3.6.0, 3.5.2
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Implement a Translator which accepts a customizable Anonymizer and translates
> a traversal into a String for logging, stripped of all identifiable user data
> (ids, property names, property values, etc.). Provide a default Anonymizer
> implementation based on Java datatype, for example:
>
>
> {code:java}
> "g.V().has('runways',inside(1,3)).values('code','airport').toList()"
> ->
> "g.V().has(string0,P.gt(integer0).and(P.lt(integer1))).values(string1,string2).toList()"
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (TINKERPOP-2663) Support Vertex references in grammar
[
https://issues.apache.org/jira/browse/TINKERPOP-2663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17465867#comment-17465867
]
ASF GitHub Bot commented on TINKERPOP-2663:
---
spmallette merged pull request #1516:
URL: https://github.com/apache/tinkerpop/pull/1516
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@tinkerpop.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Support Vertex references in grammar
>
>
> Key: TINKERPOP-2663
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2663
> Project: TinkerPop
> Issue Type: Improvement
> Components: language
>Affects Versions: 3.5.1
>Reporter: Stephen Mallette
>Assignee: Stephen Mallette
>Priority: Major
>
> With Java (and other variants) you can create an {{Element}} easy enough -
> {{ReferenceVertex}} and the like have easy to use constructors.
> {{gremlin-language}} could be made more consistent with such syntax:
> {code}
> g.addE('knows).from(Vertex(1)).to(Vertex(2))
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (TINKERPOP-2663) Support Vertex references in grammar
[
https://issues.apache.org/jira/browse/TINKERPOP-2663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Mallette closed TINKERPOP-2663.
---
Fix Version/s: 3.6.0
Resolution: Done
> Support Vertex references in grammar
>
>
> Key: TINKERPOP-2663
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2663
> Project: TinkerPop
> Issue Type: Improvement
> Components: language
>Affects Versions: 3.5.1
>Reporter: Stephen Mallette
>Assignee: Stephen Mallette
>Priority: Major
> Fix For: 3.6.0
>
>
> With Java (and other variants) you can create an {{Element}} easy enough -
> {{ReferenceVertex}} and the like have easy to use constructors.
> {{gremlin-language}} could be made more consistent with such syntax:
> {code}
> g.addE('knows).from(Vertex(1)).to(Vertex(2))
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
Re: [DISCUSS] Gryo 4.0
Just to clarify, I think you are suggesting the removal of the remaining deprecated GryoMessageSerializer instances thus removing Gryo as a network serialization option at 3.6.0. We would retain Gryo as it pertains to being a file storage format. We removed Gryo Lite for 3.6.0, so complete removal isn't too far around the corner. I dont think I have any problems with just doing it all for 3.6.0. It would continue to simplify the serialization story if it wasn't around. If we could then get Javascript on GraphBinary, we could then retire typed GraphSON versions and promote a simple GraphSON format for HTTP (like GraphSON 1.0). On Mon, Dec 27, 2021 at 7:56 AM Divij Vaidya wrote: > I agree about sun setting Gryo perhaps starting with the 3.6.x release. > > The reasons for removing it from the code base are as follows: > 1. Gryo serilization of properties is not consistent with the GraphBinary > or Graphson. As an example, Gryo tries to fetch the label of the parent > element when serializing a property whereas other serializers only provide > the ID of the parent element. > 2. GraphBinary is a direct replacement with binary serialization support > and better performance. GraphBinary support has also been expanded to > Python and is the default serializer starting 3.5.x release train. > > Divij Vaidya > > > > On Wed, Aug 26, 2020 at 10:28 AM Stephen Mallette > wrote: > > > I was just perusing JIRA a bit and came across an item to upgrade to Kryo > > 4.0 for a performance enhancement: > > > > https://issues.apache.org/jira/browse/TINKERPOP-2398 > > > > As I commented on that issue, which has not yet gotten a response, I > > believe that upgrading to Kryo 4.0 breaks binary compatibility with Kryo > > 3.0 which would mean we would probably need to stamp out Gryo 4.0 as a > > result. > > > > I'm not sure I see the need to produce another version of Gryo as we've > > deprecated it in Gremlin Server already and are pushing for wider use of > > GraphBinary as a replacement for Gryo and GraphSON for network > > serialization. I'm not sure where that leaves us with disk serialization > > but the limitation Gryo has in not working off the JVM hampers it a bit > for > > what I think of as our current usage these days. > > > > I'm inclined to continue us on a path to full deprecation of Gryo, even > for > > disk, in favor of GraphBinary, in which case, I don't think it's in our > > interest to introduce Gryo 4.0. Does anyone have any thoughts on this > > topic? > > >
[jira] [Commented] (TINKERPOP-848) Support default attribute values in GraphMLReader
[ https://issues.apache.org/jira/browse/TINKERPOP-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17465851#comment-17465851 ] ASF GitHub Bot commented on TINKERPOP-848: -- amatiushkin commented on pull request #1485: URL: https://github.com/apache/tinkerpop/pull/1485#issuecomment-1001710342 @spmallette Thanks for the ping. I'll close this PR for now and re-open once it is ready for a review. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@tinkerpop.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Support default attribute values in GraphMLReader > - > > Key: TINKERPOP-848 > URL: https://issues.apache.org/jira/browse/TINKERPOP-848 > Project: TinkerPop > Issue Type: Improvement > Components: io >Affects Versions: 3.0.2-incubating >Reporter: Pavel Klinov >Priority: Trivial > Original Estimate: 2h > Remaining Estimate: 2h > > Looking at the code of GraphMLReader I see that it doesn't support default > values of attributes, which are allowed by the GraphML spec. This is a bit > annoying especially if the input defines default values for attributes which > are used for mandatory data, e.g. edge labels. > One small example is the sample graph at [1]. "d_e" is the label attribute > with a default value. There're elements w/o body later in the > document and reading those will throw a "java.lang.IllegalArgumentException: > Label can not be null" exception (if the vendor considers edge labels > mandatory). > I'd personaly squash both keyIdMap and keyTypesMap into a single String -> > AttrInfo map, where AttrInfo would contain information about the data > attribute name, type, and the default value. > [1] http://www.eecs.wsu.edu/~yyao/DirectedStudyI/Datasets/AS/sample.graphml -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (TINKERPOP-848) Support default attribute values in GraphMLReader
[ https://issues.apache.org/jira/browse/TINKERPOP-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17465852#comment-17465852 ] ASF GitHub Bot commented on TINKERPOP-848: -- amatiushkin closed pull request #1485: URL: https://github.com/apache/tinkerpop/pull/1485 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@tinkerpop.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Support default attribute values in GraphMLReader > - > > Key: TINKERPOP-848 > URL: https://issues.apache.org/jira/browse/TINKERPOP-848 > Project: TinkerPop > Issue Type: Improvement > Components: io >Affects Versions: 3.0.2-incubating >Reporter: Pavel Klinov >Priority: Trivial > Original Estimate: 2h > Remaining Estimate: 2h > > Looking at the code of GraphMLReader I see that it doesn't support default > values of attributes, which are allowed by the GraphML spec. This is a bit > annoying especially if the input defines default values for attributes which > are used for mandatory data, e.g. edge labels. > One small example is the sample graph at [1]. "d_e" is the label attribute > with a default value. There're elements w/o body later in the > document and reading those will throw a "java.lang.IllegalArgumentException: > Label can not be null" exception (if the vendor considers edge labels > mandatory). > I'd personaly squash both keyIdMap and keyTypesMap into a single String -> > AttrInfo map, where AttrInfo would contain information about the data > attribute name, type, and the default value. > [1] http://www.eecs.wsu.edu/~yyao/DirectedStudyI/Datasets/AS/sample.graphml -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (TINKERPOP-2635) Consistent by() behavior
[
https://issues.apache.org/jira/browse/TINKERPOP-2635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17465836#comment-17465836
]
ASF GitHub Bot commented on TINKERPOP-2635:
---
anassisi2 commented on pull request #1514:
URL: https://github.com/apache/tinkerpop/pull/1514#issuecomment-1001693874
Thank you Stephen!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@tinkerpop.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Consistent by() behavior
>
>
> Key: TINKERPOP-2635
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2635
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.5.1
>Reporter: Stephen Mallette
>Assignee: Stephen Mallette
>Priority: Major
> Labels: breaking
> Fix For: 3.6.0
>
>
> A {{by()}} is deemed "unproductive" when it does not produce a value (i.e.
> where the {{hasNext()}} is {{false}}). As of 3.5.x you can get an exception
> or a {{null}} in those cases:
> {code}
> gremlin> g.V().group().by('age') // null behavior
> ==>[null:[v[3],v[5]],32:[v[4]],35:[v[6]],27:[v[2]],29:[v[1]]]
> gremlin> g.V().aggregate('a').by(out()).cap('a') // exception behavior
> The provided traverser does not map to a value: v[2]->[VertexStep(OUT,vertex)]
> Type ':help' or ':h' for help.
> Display stack trace? [yN]n
> {code}
> The {{by(String)}} behavior for this introduce in 3.5.x has become a bit of a
> special case around {{by()}} and as we are slowly removing exceptions for
> cleaner behavior in Gremlin, there clearly needs to be a more consistent
> approach taken here. Here are some problems with how things are now:
> 1. {{by(String)}} is a bit too much of a special case and is now inconsistent
> with the other forms of {{by()}} which continue to throw runtime exceptions
> (which isn’t desirable either).
> 2. By propagating a {{null}} from an unproductive {{by()}}, it becomes
> impossible to distinguish between a {{null}} property value (from an existing
> property) and a property that is simply missing.
> 3. Traversals that use {{simplePath()}} or {{cyclicPath()}} with unproductive
> {{by()}} modulators might lead to confusing results where generated {{null}}
> values create an unexpected equality. Of course, this may be considered an
> orthogonal issue, as it might also be possible to change or parameterize
> these steps to handle {{null}} differently.
> 4. The {{dedup()}} step will return the first by() modulator that returns
> {{null}} which might be unexpected.
> To bring some consistent behavior to this situation an unproductive {{by()}}
> will simply filter results for all steps. How that filtering is applied is
> specific to the step itself but generally speaking the filtering will either:
> 1. Filter the traverser or otherwise,
> 2. Ignore the traverser for purpose of constructing a side-effect.
> As this sort of filtering might make Gremlin harder to debug, TINKERPOP-2634
> will improve the ability to debug traversals, via {{DebugStrategy}}, which in
> and of itself is a well requested feature. The {{DebugStrategy}} would let
> users know about unproductive {{by()}} modulators by simply throwing an
> exception as it does in 3.4.x. It will accomplish this by converting every
> {{by()}} modulator to this pattern: {{coalesce(, fail())}} where
> {{fail()}} would be a new step that kills the traversal by raising an
> exception (a feature that has long been asked for). In addition to
> {{fail()}}, there could also be more of a soft warning in the form of a log
> or trace if that is desired. This pattern could be implemented as a
> GraphTraversal or a special case implementation of {{Traversal}} (like,
> {{ValueTraversal}}), but the key point is that there would now be a way to be
> aware of unproductive {{by()}} filters while developing your application.
> This change in behavior does not have to be a breaking change. The
> introduction of a new {{ProductiveByStrategy}} could unify all {by()}}
> behavior to produce a {{null}}. This strategy would wrap {{by()}} modulators
> in {{coalesce(, constant(null))}} and be installed by default. It could
> even be made configurable to take the keys to which it would apply leaving
> Gremlin in a more optimized state in such cases. The default behavior without
> this strategy would be changed to filter. For 3.6.0, the
> {{ProductiveByStrategy}} could be removed as a default strategy with the
> option for users to add it back in to maintain the 3.5.x functionality.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (TINKERPOP-2635) Consistent by() behavior
[
https://issues.apache.org/jira/browse/TINKERPOP-2635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17465832#comment-17465832
]
ASF GitHub Bot commented on TINKERPOP-2635:
---
spmallette commented on pull request #1514:
URL: https://github.com/apache/tinkerpop/pull/1514#issuecomment-1001684051
you may ask question in Discord, stackoverflow, etc. Quickly though, you
probably need to just import `outE()`:
https://tinkerpop.apache.org/docs/current/reference/#gremlin-javascript-imports
```js
const __ = gremlin.process.statics;
```
and then you should be able to reference it as `__.outE()` or import it as
`outE()` explicitly.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@tinkerpop.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Consistent by() behavior
>
>
> Key: TINKERPOP-2635
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2635
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.5.1
>Reporter: Stephen Mallette
>Assignee: Stephen Mallette
>Priority: Major
> Labels: breaking
> Fix For: 3.6.0
>
>
> A {{by()}} is deemed "unproductive" when it does not produce a value (i.e.
> where the {{hasNext()}} is {{false}}). As of 3.5.x you can get an exception
> or a {{null}} in those cases:
> {code}
> gremlin> g.V().group().by('age') // null behavior
> ==>[null:[v[3],v[5]],32:[v[4]],35:[v[6]],27:[v[2]],29:[v[1]]]
> gremlin> g.V().aggregate('a').by(out()).cap('a') // exception behavior
> The provided traverser does not map to a value: v[2]->[VertexStep(OUT,vertex)]
> Type ':help' or ':h' for help.
> Display stack trace? [yN]n
> {code}
> The {{by(String)}} behavior for this introduce in 3.5.x has become a bit of a
> special case around {{by()}} and as we are slowly removing exceptions for
> cleaner behavior in Gremlin, there clearly needs to be a more consistent
> approach taken here. Here are some problems with how things are now:
> 1. {{by(String)}} is a bit too much of a special case and is now inconsistent
> with the other forms of {{by()}} which continue to throw runtime exceptions
> (which isn’t desirable either).
> 2. By propagating a {{null}} from an unproductive {{by()}}, it becomes
> impossible to distinguish between a {{null}} property value (from an existing
> property) and a property that is simply missing.
> 3. Traversals that use {{simplePath()}} or {{cyclicPath()}} with unproductive
> {{by()}} modulators might lead to confusing results where generated {{null}}
> values create an unexpected equality. Of course, this may be considered an
> orthogonal issue, as it might also be possible to change or parameterize
> these steps to handle {{null}} differently.
> 4. The {{dedup()}} step will return the first by() modulator that returns
> {{null}} which might be unexpected.
> To bring some consistent behavior to this situation an unproductive {{by()}}
> will simply filter results for all steps. How that filtering is applied is
> specific to the step itself but generally speaking the filtering will either:
> 1. Filter the traverser or otherwise,
> 2. Ignore the traverser for purpose of constructing a side-effect.
> As this sort of filtering might make Gremlin harder to debug, TINKERPOP-2634
> will improve the ability to debug traversals, via {{DebugStrategy}}, which in
> and of itself is a well requested feature. The {{DebugStrategy}} would let
> users know about unproductive {{by()}} modulators by simply throwing an
> exception as it does in 3.4.x. It will accomplish this by converting every
> {{by()}} modulator to this pattern: {{coalesce(, fail())}} where
> {{fail()}} would be a new step that kills the traversal by raising an
> exception (a feature that has long been asked for). In addition to
> {{fail()}}, there could also be more of a soft warning in the form of a log
> or trace if that is desired. This pattern could be implemented as a
> GraphTraversal or a special case implementation of {{Traversal}} (like,
> {{ValueTraversal}}), but the key point is that there would now be a way to be
> aware of unproductive {{by()}} filters while developing your application.
> This change in behavior does not have to be a breaking change. The
> introduction of a new {{ProductiveByStrategy}} could unify all {by()}}
> behavior to produce a {{null}}. This strategy would wrap {{by()}} modulators
> in {{coalesce(, constant(null))}} and be installed by default. It could
> even be made configurable to take the keys to which it would apply leaving
> Gremlin
[jira] [Commented] (TINKERPOP-2635) Consistent by() behavior
[
https://issues.apache.org/jira/browse/TINKERPOP-2635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17465826#comment-17465826
]
ASF GitHub Bot commented on TINKERPOP-2635:
---
anassisi2 commented on pull request #1514:
URL: https://github.com/apache/tinkerpop/pull/1514#issuecomment-1001678276
Hi Stephen,
I'm not sure where to post the issue below, it seems you are working on
gremlin-javascript.
I get a "ReferenceError: outE is not defined" when I use it after local or
repeat like:
g.V().hasLabel('assembly', 'part').
local(outE("version").order().by('ver', desc).limit(1)).inV().
path().
by(__.elementMap()).
by(__.valueMap()).
by(__.valueMap()).
toList();
I'm using ver 3.5.1 installed via Npm.
Thank you,
Andrea
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@tinkerpop.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Consistent by() behavior
>
>
> Key: TINKERPOP-2635
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2635
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.5.1
>Reporter: Stephen Mallette
>Assignee: Stephen Mallette
>Priority: Major
> Labels: breaking
> Fix For: 3.6.0
>
>
> A {{by()}} is deemed "unproductive" when it does not produce a value (i.e.
> where the {{hasNext()}} is {{false}}). As of 3.5.x you can get an exception
> or a {{null}} in those cases:
> {code}
> gremlin> g.V().group().by('age') // null behavior
> ==>[null:[v[3],v[5]],32:[v[4]],35:[v[6]],27:[v[2]],29:[v[1]]]
> gremlin> g.V().aggregate('a').by(out()).cap('a') // exception behavior
> The provided traverser does not map to a value: v[2]->[VertexStep(OUT,vertex)]
> Type ':help' or ':h' for help.
> Display stack trace? [yN]n
> {code}
> The {{by(String)}} behavior for this introduce in 3.5.x has become a bit of a
> special case around {{by()}} and as we are slowly removing exceptions for
> cleaner behavior in Gremlin, there clearly needs to be a more consistent
> approach taken here. Here are some problems with how things are now:
> 1. {{by(String)}} is a bit too much of a special case and is now inconsistent
> with the other forms of {{by()}} which continue to throw runtime exceptions
> (which isn’t desirable either).
> 2. By propagating a {{null}} from an unproductive {{by()}}, it becomes
> impossible to distinguish between a {{null}} property value (from an existing
> property) and a property that is simply missing.
> 3. Traversals that use {{simplePath()}} or {{cyclicPath()}} with unproductive
> {{by()}} modulators might lead to confusing results where generated {{null}}
> values create an unexpected equality. Of course, this may be considered an
> orthogonal issue, as it might also be possible to change or parameterize
> these steps to handle {{null}} differently.
> 4. The {{dedup()}} step will return the first by() modulator that returns
> {{null}} which might be unexpected.
> To bring some consistent behavior to this situation an unproductive {{by()}}
> will simply filter results for all steps. How that filtering is applied is
> specific to the step itself but generally speaking the filtering will either:
> 1. Filter the traverser or otherwise,
> 2. Ignore the traverser for purpose of constructing a side-effect.
> As this sort of filtering might make Gremlin harder to debug, TINKERPOP-2634
> will improve the ability to debug traversals, via {{DebugStrategy}}, which in
> and of itself is a well requested feature. The {{DebugStrategy}} would let
> users know about unproductive {{by()}} modulators by simply throwing an
> exception as it does in 3.4.x. It will accomplish this by converting every
> {{by()}} modulator to this pattern: {{coalesce(, fail())}} where
> {{fail()}} would be a new step that kills the traversal by raising an
> exception (a feature that has long been asked for). In addition to
> {{fail()}}, there could also be more of a soft warning in the form of a log
> or trace if that is desired. This pattern could be implemented as a
> GraphTraversal or a special case implementation of {{Traversal}} (like,
> {{ValueTraversal}}), but the key point is that there would now be a way to be
> aware of unproductive {{by()}} filters while developing your application.
> This change in behavior does not have to be a breaking change. The
> introduction of a new {{ProductiveByStrategy}} could unify all {by()}}
> behavior to produce a {{null}}. This strategy would wrap {{by()}} modulators
> in {{coalesce(, constant(null))}} a
Re: [DISCUSS] Gryo 4.0
I agree about sun setting Gryo perhaps starting with the 3.6.x release. The reasons for removing it from the code base are as follows: 1. Gryo serilization of properties is not consistent with the GraphBinary or Graphson. As an example, Gryo tries to fetch the label of the parent element when serializing a property whereas other serializers only provide the ID of the parent element. 2. GraphBinary is a direct replacement with binary serialization support and better performance. GraphBinary support has also been expanded to Python and is the default serializer starting 3.5.x release train. Divij Vaidya On Wed, Aug 26, 2020 at 10:28 AM Stephen Mallette wrote: > I was just perusing JIRA a bit and came across an item to upgrade to Kryo > 4.0 for a performance enhancement: > > https://issues.apache.org/jira/browse/TINKERPOP-2398 > > As I commented on that issue, which has not yet gotten a response, I > believe that upgrading to Kryo 4.0 breaks binary compatibility with Kryo > 3.0 which would mean we would probably need to stamp out Gryo 4.0 as a > result. > > I'm not sure I see the need to produce another version of Gryo as we've > deprecated it in Gremlin Server already and are pushing for wider use of > GraphBinary as a replacement for Gryo and GraphSON for network > serialization. I'm not sure where that leaves us with disk serialization > but the limitation Gryo has in not working off the JVM hampers it a bit for > what I think of as our current usage these days. > > I'm inclined to continue us on a path to full deprecation of Gryo, even for > disk, in favor of GraphBinary, in which case, I don't think it's in our > interest to introduce Gryo 4.0. Does anyone have any thoughts on this > topic? >
