[jira] [Commented] (TINKERPOP-2243) Add user-agent to RequestOptions
[ https://issues.apache.org/jira/browse/TINKERPOP-2243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16866600#comment-16866600 ] Bryn Cooke commented on TINKERPOP-2243: --- BTW I do see the value in trying to generically expose the request headers to the client. Many of the existing Tokens should probably make their way there rather than residing in the payload. This will be a much larger refactor. > Add user-agent to RequestOptions > > > Key: TINKERPOP-2243 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2243 > Project: TinkerPop > Issue Type: Improvement > Components: driver, server >Affects Versions: 3.4.2 >Reporter: Bryn Cooke >Priority: Major > > It would be useful to know the 'user-agent' that is sending a request so that > the server can react in different ways. For instance: > * To log differently. > * To give different error messages. > For instance, if the user is connecting via gremlin console then error > messages can include gremlin console specific help. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2243) Add user-agent to RequestOptions
[ https://issues.apache.org/jira/browse/TINKERPOP-2243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16866386#comment-16866386 ] Bryn Cooke commented on TINKERPOP-2243: --- When sending a request there is already an arbitrary map that is populated from the RequestOptions and could be extended to allow custom fields, but is probably out of scope for this ticket. I'd be keen on not having any of this auto-magically wired up based on the classpath. What happens if the user has two clients in the same process but want different fields? What if the fields that are sent with the request are not static? > Add user-agent to RequestOptions > > > Key: TINKERPOP-2243 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2243 > Project: TinkerPop > Issue Type: Improvement > Components: driver, server >Affects Versions: 3.4.2 >Reporter: Bryn Cooke >Priority: Major > > It would be useful to know the 'user-agent' that is sending a request so that > the server can react in different ways. For instance: > * To log differently. > * To give different error messages. > For instance, if the user is connecting via gremlin console then error > messages can include gremlin console specific help. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (TINKERPOP-2243) Add user-agent to RequestOptions
[ https://issues.apache.org/jira/browse/TINKERPOP-2243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryn Cooke updated TINKERPOP-2243: -- Description: It would be useful to know the 'user-agent' that is sending a request so that the server can react in different ways. For instance: * To log differently. * To give different error messages. For instance, if the user is connecting via gremlin console then error messages can include gremlin console specific help. was: It would be useful to know the 'user-agent' that is sending a request so that the server can react in different ways. For instance: * To log differently. * To give different error messages. > Add user-agent to RequestOptions > > > Key: TINKERPOP-2243 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2243 > Project: TinkerPop > Issue Type: Improvement > Components: driver, server >Affects Versions: 3.4.2 >Reporter: Bryn Cooke >Priority: Major > > It would be useful to know the 'user-agent' that is sending a request so that > the server can react in different ways. For instance: > * To log differently. > * To give different error messages. > For instance, if the user is connecting via gremlin console then error > messages can include gremlin console specific help. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TINKERPOP-2243) Add user-agent to RequestOptions
Bryn Cooke created TINKERPOP-2243: - Summary: Add user-agent to RequestOptions Key: TINKERPOP-2243 URL: https://issues.apache.org/jira/browse/TINKERPOP-2243 Project: TinkerPop Issue Type: Improvement Components: driver, server Affects Versions: 3.4.2 Reporter: Bryn Cooke It would be useful to know the 'user-agent' that is sending a request so that the server can react in different ways. For instance: * To log differently. * To give different error messages. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TINKERPOP-2183) InterpreterModeASTTransformation needs to be more specific about what it transforms
Bryn Cooke created TINKERPOP-2183:
-
Summary: InterpreterModeASTTransformation needs to be more
specific about what it transforms
Key: TINKERPOP-2183
URL: https://issues.apache.org/jira/browse/TINKERPOP-2183
Project: TinkerPop
Issue Type: Bug
Components: server
Reporter: Bryn Cooke
Currently if you declare a class within a script it will get incorrectly
processed by
{{InterpreterModeASTTransformation}} usually resulting in an exception.
{{InterpreterModeASTTransformation#visit}} should check that it is being
applied to a class that extends {{Script}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2161) GraphBinary: Write serialization performance issue
[
https://issues.apache.org/jira/browse/TINKERPOP-2161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16771016#comment-16771016
]
Bryn Cooke commented on TINKERPOP-2161:
---
Would it be possible to add Gryo serialization to this benchmark?
This would give us a better idea of if we will be able to move to using the new
binary format.
> GraphBinary: Write serialization performance issue
> ---
>
> Key: TINKERPOP-2161
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2161
> Project: TinkerPop
> Issue Type: Bug
> Components: io
>Affects Versions: 3.4.0
>Reporter: Jorge Bay
>Priority: Major
>
> There seems to be a performance issue regarding the write path in GraphBinary:
> {code}
> Benchmark Mode Cnt Score
> Error Units
> SerializationBenchmark.testReadMessage1Binary thrpt 20 4800832.981 ±
> 430909.102 ops/s
> SerializationBenchmark.testReadMessage1GraphSON thrpt 20 34109.669 ±
> 5231.210 ops/s
> SerializationBenchmark.testReadMessage2Binary thrpt 20827266.707 ±
> 78214.379 ops/s
> SerializationBenchmark.testReadMessage2GraphSON thrpt 20 18462.919 ±
> 2640.093 ops/s
> SerializationBenchmark.testWriteBytecodeBinarythrpt 20130486.109 ±
> 5505.113 ops/s
> SerializationBenchmark.testWriteBytecodeGraphSON thrpt 20592658.686 ±
> 68063.966 ops/s
> SerializationBenchmark.testWriteResponseBinarythrpt 20290240.715 ±
> 25620.656 ops/s
> SerializationBenchmark.testWriteResponseGraphSON thrpt 20612832.036 ±
> 48173.673 ops/s
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (TINKERPOP-1869) Profile step and iterate do not play nicely with each other
Bryn Cooke created TINKERPOP-1869: - Summary: Profile step and iterate do not play nicely with each other Key: TINKERPOP-1869 URL: https://issues.apache.org/jira/browse/TINKERPOP-1869 Project: TinkerPop Issue Type: Bug Components: process Affects Versions: 3.3.1 Reporter: Bryn Cooke Profile step doesn't like it if there are any other steps after it. However if someone calls profile().iterate() they will get an error as iterate appends a NoneStep to the end of the traversal. Even though this means that the results of the profile would never be returned I think that profile step should allow None step to follow it. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TINKERPOP-1833) DetachedEdge.Builder#setInV and setOutV doesn't return the builder
Bryn Cooke created TINKERPOP-1833: - Summary: DetachedEdge.Builder#setInV and setOutV doesn't return the builder Key: TINKERPOP-1833 URL: https://issues.apache.org/jira/browse/TINKERPOP-1833 Project: TinkerPop Issue Type: Improvement Components: structure Affects Versions: 3.2.6 Reporter: Bryn Cooke Priority: Trivial It seems strange that DetachedEdge.Builder#setInV and setOutV doesn't return the builder when the rest of the methods do. It wouldn't be a breaking change to fix this. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TINKERPOP-1828) AddPropertyStep doesn't attach vertex to DetachedElements for new properties
Bryn Cooke created TINKERPOP-1828: - Summary: AddPropertyStep doesn't attach vertex to DetachedElements for new properties Key: TINKERPOP-1828 URL: https://issues.apache.org/jira/browse/TINKERPOP-1828 Project: TinkerPop Issue Type: Improvement Components: process Affects Versions: 3.2.6 Reporter: Bryn Cooke Here even though a detached vertex is created it is not passed in to the constructor of the DetachedVertexProperty or DetachedProperty. This makes things slightly more awkward when using the events later. https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/sideEffect/AddPropertyStep.java#L99-L108 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TINKERPOP-1813) Subgraph step requires the graph API
[ https://issues.apache.org/jira/browse/TINKERPOP-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16236023#comment-16236023 ] Bryn Cooke commented on TINKERPOP-1813: --- Why not have the default implementation use nested traversals? I am wary of replacing existing steps as this has the high chance of creating some difference in behaviour. > Subgraph step requires the graph API > > > Key: TINKERPOP-1813 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1813 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.2.6 >Reporter: Bryn Cooke >Assignee: Marko A. Rodriguez >Priority: Minor > > SubgraphStrategy uses the graph API to create elements in the subgraph. If a > graph does not fully support the graph/structure API this it won't work. > Ideally the graph mutations should use the traversal API. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TINKERPOP-1815) Graph io requires the graph API
Bryn Cooke created TINKERPOP-1815: - Summary: Graph io requires the graph API Key: TINKERPOP-1815 URL: https://issues.apache.org/jira/browse/TINKERPOP-1815 Project: TinkerPop Issue Type: Improvement Components: io Reporter: Bryn Cooke Currently the io classes use the graph API to populate the graph. For graphs that do not fully support the graph API means that standard IO won't work. It would be great if io could use the traversal API for constructing the graph. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TINKERPOP-1814) Some process tests require the graph API
Bryn Cooke created TINKERPOP-1814: - Summary: Some process tests require the graph API Key: TINKERPOP-1814 URL: https://issues.apache.org/jira/browse/TINKERPOP-1814 Project: TinkerPop Issue Type: Test Components: process Affects Versions: 3.2.6 Reporter: Bryn Cooke This test uses the graph API: https://github.com/apache/tinkerpop/blob/master/gremlin-test/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/map/AddEdgeTest.java#L137-L142 This test assumes that the reference to the vertex will be updated. It should at least fetch the vertex again after it has been updated, but ideally use a traversal for verification. https://github.com/apache/tinkerpop/blob/master/gremlin-test/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/strategy/decoration/PartitionStrategyProcessTest.java#L142-L143 These tests disable the strategies supplied by the implementing graph and therefore they will default to using the graph API under the hood. https://github.com/apache/tinkerpop/blob/master/gremlin-test/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/CoreTraversalTest.java#L222-L261 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TINKERPOP-1813) Subgraph strategy requires the graph API
Bryn Cooke created TINKERPOP-1813: - Summary: Subgraph strategy requires the graph API Key: TINKERPOP-1813 URL: https://issues.apache.org/jira/browse/TINKERPOP-1813 Project: TinkerPop Issue Type: Improvement Components: process Affects Versions: 3.2.6 Reporter: Bryn Cooke SubgraphStrategy uses the graph API to create elements in the subgraph. If a graph does not fully support the graph/structure API this it won't work. Ideally the graph mutations should use the traversal API. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TINKERPOP-1812) ProfileTest assumes that graph implementations will not add their own steps
Bryn Cooke created TINKERPOP-1812: - Summary: ProfileTest assumes that graph implementations will not add their own steps Key: TINKERPOP-1812 URL: https://issues.apache.org/jira/browse/TINKERPOP-1812 Project: TinkerPop Issue Type: Test Components: process Affects Versions: 3.2.6 Reporter: Bryn Cooke The following two tests check the number of steps in the traversal: g_V_sideEffectXThread_sleepX10XX_sideEffectXThread_sleepX5XX_profileXmetricsX g_V_sideEffectXThread_sleepX10XX_sideEffectXThread_sleepX5XX_profile This assumes that graph implementations add no steps to the traversal. They should probably be checking the structure of the traversal rather than the total number of steps. For instance that each step is followed by a profile step and that the profile side effect step and cap step are the last steps. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1808) Add ability to get the consumer in LambdaSideEffectStep
[ https://issues.apache.org/jira/browse/TINKERPOP-1808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryn Cooke updated TINKERPOP-1808: -- Description: When lambda steps are used in a traversal it would be helpful to allow access to the contained lambda so that it can be wrapped without fundamentally changing the structure of the traversal. Obtaining the lambda means that a strategy may wrap the lambda to provide extra security context, or event collection. was: When lambdas are used in a traversal it would be helpful to allow access to the contained lambda so that it can be wrapped without fundamentally changing the structure of the traversal. Obtaining the lambda means that a strategy may wrap the lambda to provide extra security context, or event collection. > Add ability to get the consumer in LambdaSideEffectStep > --- > > Key: TINKERPOP-1808 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1808 > Project: TinkerPop > Issue Type: Improvement > Components: process >Reporter: Bryn Cooke >Priority: Minor > > When lambda steps are used in a traversal it would be helpful to allow access > to the contained lambda so that it can be wrapped without fundamentally > changing the structure of the traversal. > Obtaining the lambda means that a strategy may wrap the lambda to provide > extra security context, or event collection. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TINKERPOP-1808) Add ability to get the consumer in LambdaSideEffectStep
Bryn Cooke created TINKERPOP-1808: - Summary: Add ability to get the consumer in LambdaSideEffectStep Key: TINKERPOP-1808 URL: https://issues.apache.org/jira/browse/TINKERPOP-1808 Project: TinkerPop Issue Type: Improvement Components: process Reporter: Bryn Cooke Priority: Minor When lambdas are used in a traversal it would be helpful to allow access to the contained lambda so that it can be wrapped without fundamentally changing the structure of the traversal. Obtaining the lambda means that a strategy may wrap the lambda to provide extra security context, or event collection. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TINKERPOP-1798) MutationListener.vertexPropertyChanged oldValue should be a VertexProperty
Bryn Cooke created TINKERPOP-1798:
-
Summary: MutationListener.vertexPropertyChanged oldValue should be
a VertexProperty
Key: TINKERPOP-1798
URL: https://issues.apache.org/jira/browse/TINKERPOP-1798
Project: TinkerPop
Issue Type: Bug
Components: process
Affects Versions: 3.2.6
Reporter: Bryn Cooke
Priority: Minor
Currently the signature looks like this:
{noformat}
public void vertexPropertyChanged(final Vertex element, final Property
oldValue, final Object setValue, final Object... vertexPropertyKeyValues);
{noformat}
But should probably be:
{noformat}
public void vertexPropertyChanged(final Vertex element, final VertexProperty
oldValue, final Object setValue, final Object... vertexPropertyKeyValues);
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1703) Make EdgeOtherVertexStep non-final
[ https://issues.apache.org/jira/browse/TINKERPOP-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryn Cooke updated TINKERPOP-1703: -- Summary: Make EdgeOtherVertexStep non-final (was: Make DsegEdgeOtherVertexStep non-final) > Make EdgeOtherVertexStep non-final > -- > > Key: TINKERPOP-1703 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1703 > Project: TinkerPop > Issue Type: Improvement > Components: process >Reporter: Bryn Cooke > > I missed this in TINKERPOP-1669. > To recap, having element steps non final is helpful to implementations as > they can leave the majority of the traversal steps alone, and only replace > the element steps. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TINKERPOP-1703) Make DsegEdgeOtherVertexStep non-final
Bryn Cooke created TINKERPOP-1703: - Summary: Make DsegEdgeOtherVertexStep non-final Key: TINKERPOP-1703 URL: https://issues.apache.org/jira/browse/TINKERPOP-1703 Project: TinkerPop Issue Type: Improvement Components: process Reporter: Bryn Cooke I missed this in TINKERPOP-1669. To recap, having element steps non final is helpful to implementations as they can leave the majority of the traversal steps alone, and only replace the element steps. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (TINKERPOP-1569) Decompile lambdas in to regular gremlin
[ https://issues.apache.org/jira/browse/TINKERPOP-1569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryn Cooke closed TINKERPOP-1569. - Resolution: Won't Fix > Decompile lambdas in to regular gremlin > --- > > Key: TINKERPOP-1569 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1569 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.2.3 >Reporter: Bryn Cooke > > I've been experimenting recently with decompilation and come up with this > method for decompiling lambdas: > https://github.com/BrynCooke/dice/blob/master/lambda/src/test/java/org/jglue/dice/lambda/TestDecompiler.java > Perhaps this could be useful for converting lamdas to regular gremlin? > It only works with serializable lambdas BTW. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TINKERPOP-1669) EdgeVertexStep should be designed for extension
[ https://issues.apache.org/jira/browse/TINKERPOP-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16024532#comment-16024532 ] Bryn Cooke commented on TINKERPOP-1669: --- I have recently embarked upon a review of how we are integrating our graph implementation with Tinkerpop. Previously we had significant traversal rewriting going on, and would add and remove steps. However, it turns out that maintaining correctness when doing this is actually quite hard. Instead I am taking a much less invasive approach by simply replacing the element steps with internal classes while leaving the rest of the traversal alone. This has a couple of advantages: 1. It's much easier to reason about. 2. We can optimise for much more complicated traversals, correctly handling AND and OR. If our backend can't mimic the expressiveness of TP we can do as much as possible and allow the TP traversal to handle the rest. > EdgeVertexStep should be designed for extension > --- > > Key: TINKERPOP-1669 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1669 > Project: TinkerPop > Issue Type: Improvement > Components: process, structure >Affects Versions: 3.2.4 >Reporter: Bryn Cooke > > GraphStep, VertexStep and PropertiesStep are all not final, so I was > surprised to find that I couldn't extend EdgeVertexStep. In the end I had to > duplicate the entire class > If there are concerns about simply making this class non-final then it could > be designed for extension by making most of the methods final (except > toString), but the leaving the class non-final. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (TINKERPOP-1637) Expose metrics attributes in string output
[
https://issues.apache.org/jira/browse/TINKERPOP-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16024495#comment-16024495
]
Bryn Cooke commented on TINKERPOP-1637:
---
Something like:
{noformat}
gremlin> g =
EmptyGraph.instance().traversal().withRemote('conf/remote-graph.properties')
==>graphtraversalsource[emptygraph[empty], standard]
gremlin> g.V().out().out().profile().next().toString()
==>Traversal Metrics
Step Count
Traversers Time (ms)% Dur
=
TinkerGraphStep(vertex,[]) 1
1 0.05121.09
key1=value1
key2=value2
VertexStep(OUT,vertex)
0.06827.90
key1=value1
key3=value3
NoOpBarrierStep(2500)
0.03614.64
key1=value1
VertexStep(OUT,vertex)
0.03815.63
key1=value1
key3=value3
NoOpBarrierStep(2500)
0.05120.74
>TOTAL -
- 0.246-
{noformat}
> Expose metrics attributes in string output
> --
>
> Key: TINKERPOP-1637
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1637
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.4
>Reporter: Bryn Cooke
>
> Currently the profile step won't expose metrics attributes in the string
> output. This means that useful information provided by graph implementations
> is never output.
> It would be great if the attributes could be output indented under each
> metric.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (TINKERPOP-1637) Expose metrics attributes in string output
[ https://issues.apache.org/jira/browse/TINKERPOP-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16024494#comment-16024494 ] Bryn Cooke commented on TINKERPOP-1637: --- It is the contents of ImmutableMetrics#annotations. This map is presumably there for TP implementors to add extra implementation specific information, but as it's not output to the console it's painful for the users to get at. > Expose metrics attributes in string output > -- > > Key: TINKERPOP-1637 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1637 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.2.4 >Reporter: Bryn Cooke > > Currently the profile step won't expose metrics attributes in the string > output. This means that useful information provided by graph implementations > is never output. > It would be great if the attributes could be output indented under each > metric. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (TINKERPOP-1637) Expose metrics attributes in string output
[ https://issues.apache.org/jira/browse/TINKERPOP-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15986134#comment-15986134 ] Bryn Cooke commented on TINKERPOP-1637: --- It's any client that tries to toString the output of the profile step. > Expose metrics attributes in string output > -- > > Key: TINKERPOP-1637 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1637 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.2.4 >Reporter: Bryn Cooke > > Currently the profile step won't expose metrics attributes in the string > output. This means that useful information provided by graph implementations > is never output. > It would be great if the attributes could be output indented under each > metric. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (TINKERPOP-1669) EdgeVertexStep should be designed for extension
[ https://issues.apache.org/jira/browse/TINKERPOP-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryn Cooke updated TINKERPOP-1669: -- Description: GraphStep, VertexStep and PropertiesStep are all not final, so I was surprised to find that I couldn't extend EdgeVertexStep. In the end I had to duplicate the entire class If there are concerns about simply making this class non-final then it could be designed for extension by making most of the methods final (except toString), but the leaving the class non-final. was:GraphStep, VertexStep and PropertiesStep are all not final, so I was surprised to find that I couldn't extend EdgeVertexStep. In the end I had to duplicate the entire class > EdgeVertexStep should be designed for extension > --- > > Key: TINKERPOP-1669 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1669 > Project: TinkerPop > Issue Type: Improvement > Components: process, structure >Affects Versions: 3.2.4 >Reporter: Bryn Cooke > > GraphStep, VertexStep and PropertiesStep are all not final, so I was > surprised to find that I couldn't extend EdgeVertexStep. In the end I had to > duplicate the entire class > If there are concerns about simply making this class non-final then it could > be designed for extension by making most of the methods final (except > toString), but the leaving the class non-final. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (TINKERPOP-1669) EdgeVertexStep should be designed for extension
[ https://issues.apache.org/jira/browse/TINKERPOP-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryn Cooke updated TINKERPOP-1669: -- Summary: EdgeVertexStep should be designed for extension (was: EdgeVertexStep should not be final) > EdgeVertexStep should be designed for extension > --- > > Key: TINKERPOP-1669 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1669 > Project: TinkerPop > Issue Type: Improvement > Components: process, structure >Affects Versions: 3.2.4 >Reporter: Bryn Cooke > > GraphStep, VertexStep and PropertiesStep are all not final, so I was > surprised to find that I couldn't extend EdgeVertexStep. In the end I had to > duplicate the entire class -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (TINKERPOP-1669) EdgeVertexStep should not be final
Bryn Cooke created TINKERPOP-1669: - Summary: EdgeVertexStep should not be final Key: TINKERPOP-1669 URL: https://issues.apache.org/jira/browse/TINKERPOP-1669 Project: TinkerPop Issue Type: Improvement Components: process, structure Affects Versions: 3.2.4 Reporter: Bryn Cooke GraphStep, VertexStep and PropertiesStep are all not final, so I was surprised to find that I couldn't extend EdgeVertexStep. In the end I had to duplicate the entire class -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (TINKERPOP-1664) StarVertexProperty#property should throw an NPE if the value is null
Bryn Cooke created TINKERPOP-1664: - Summary: StarVertexProperty#property should throw an NPE if the value is null Key: TINKERPOP-1664 URL: https://issues.apache.org/jira/browse/TINKERPOP-1664 Project: TinkerPop Issue Type: Improvement Components: structure Affects Versions: 3.2.4 Reporter: Bryn Cooke Currently properties are checked for nullness but meta-properties arenot. This leads to NPEs further down the line. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (TINKERPOP-1658) Graphson2 map keys are serialised as strings
Bryn Cooke created TINKERPOP-1658: - Summary: Graphson2 map keys are serialised as strings Key: TINKERPOP-1658 URL: https://issues.apache.org/jira/browse/TINKERPOP-1658 Project: TinkerPop Issue Type: Bug Components: driver Affects Versions: 3.2.4 Reporter: Bryn Cooke If you try to serialise a map using graphson2 then if you use a key such as T.label it gets converted to a string. The value is serialised correctly. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (TINKERPOP-1644) Improve script compilation syncronisation
Bryn Cooke created TINKERPOP-1644: - Summary: Improve script compilation syncronisation Key: TINKERPOP-1644 URL: https://issues.apache.org/jira/browse/TINKERPOP-1644 Project: TinkerPop Issue Type: Improvement Affects Versions: 3.2.4 Reporter: Bryn Cooke Currently there is no synchronisation around script compilation. This means that if a particularly heavy script is in use, many threads may end up compiling the same script. It would seem like a good idea to have some some sort of synchronisation to prevent ever getting to this stage. In addition, there will be cases where users will repeatedly submit broken scripts to the server. In this case it is useful to log the error the first time the script compilation is attempted and then cache the error for subsequent runs. Finally I have found some scripts take in excess of 30 seconds to compile. To aid performance debugging the script compilation times should be included in the logs. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (TINKERPOP-1637) Expose metrics attributes in string output
Bryn Cooke created TINKERPOP-1637: - Summary: Expose metrics attributes in string output Key: TINKERPOP-1637 URL: https://issues.apache.org/jira/browse/TINKERPOP-1637 Project: TinkerPop Issue Type: Improvement Components: process Affects Versions: 3.2.4 Reporter: Bryn Cooke Currently the profile step won't expose metrics attributes in the string output. This means that useful information provided by graph implementations is never output. It would be great if the attributes could be output indented under each metric. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (TINKERPOP-1569) Decompile lambdas in to regular gremlin
Bryn Cooke created TINKERPOP-1569: - Summary: Decompile lambdas in to regular gremlin Key: TINKERPOP-1569 URL: https://issues.apache.org/jira/browse/TINKERPOP-1569 Project: TinkerPop Issue Type: Improvement Components: process Reporter: Bryn Cooke I've been experimenting recently with decompilation and come up with this method for decompiling lambdas: https://github.com/BrynCooke/dice/blob/master/lambda/src/test/java/org/jglue/dice/lambda/TestDecompiler.java Perhaps this could be useful for converting lamdas to regular gremlin? It only works with serializable lambdas BTW. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TINKERPOP-887) FastNoSuchElementException hides stack trace in client code
[ https://issues.apache.org/jira/browse/TINKERPOP-887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15617713#comment-15617713 ] Bryn Cooke commented on TINKERPOP-887: -- OK. That makes sense. I had issues with an interaction with the other strategies that were painful to resolve. I can see that adding new strategies is last resort. Taking a step back I have modified the PR so that strategies are not touched. It's much simpler. Please could you take another look? I added a basic test that checks that a traversal will throw NoSuchElementException rather than FastNoSuchElementException. This demonstrates the benefit in non-gremlin server scenarios. In future Gremlin Server can use this information to supply line precise error reporting, but that is outside the scope of this ticket. If there are more tests that you would like adding please can you point me to the package where you would see them residing? > FastNoSuchElementException hides stack trace in client code > --- > > Key: TINKERPOP-887 > URL: https://issues.apache.org/jira/browse/TINKERPOP-887 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.0.2-incubating >Reporter: Bryn Cooke >Assignee: Marko A. Rodriguez >Priority: Minor > > I wrote some code that incorrectly assumed that a Gremlin query would return > an element, but it didn't. The surprise was that I got no stack trace and > therefore had no idea where in *my* code I had introduced the error. > I haven't looked in detail at the TP code, so what comes next is speculation: > If FastNoSuchElementException is being used in truly exceptional > circumstances then why is a singleton is used over a normal exception with > stack trace? It could just as easily be converted to a normal exception. > If FastNoSuchElementException is being used for control flow then probably it > shouldn't. Code should check hasNext rather than trying for next and dealing > with an exceptional result. I'm not sure what the current state of things are > in the JVM but at least in the past try catch blocks would inhibit > optimization even without stack traces so this type of code was considered an > antipattern. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TINKERPOP-887) FastNoSuchElementException hides stack trace in client code
[ https://issues.apache.org/jira/browse/TINKERPOP-887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15616690#comment-15616690 ] Bryn Cooke commented on TINKERPOP-887: -- Is this really going to make a difference to performance? The added step is basically a no-op, so unless there is definitely a performance degradation then it'd be better to avoid the extra complexity for users having to enable a special mode. Perhaps we can evaluate the perf impact before going down this route? If we did have to have a special mode then how would this be activated? Say you have a 100 line gremlin script that you are submitting to gremlin server, you'd want to enable this mode for all traversals in the request. That way when the error occurs you can tell which line it occurred on. Perhaps [~spmallette] has some ideas? Ideally I would like to avoid having to put the entire server in to debug mode. > FastNoSuchElementException hides stack trace in client code > --- > > Key: TINKERPOP-887 > URL: https://issues.apache.org/jira/browse/TINKERPOP-887 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.0.2-incubating >Reporter: Bryn Cooke >Assignee: Marko A. Rodriguez >Priority: Minor > > I wrote some code that incorrectly assumed that a Gremlin query would return > an element, but it didn't. The surprise was that I got no stack trace and > therefore had no idea where in *my* code I had introduced the error. > I haven't looked in detail at the TP code, so what comes next is speculation: > If FastNoSuchElementException is being used in truly exceptional > circumstances then why is a singleton is used over a normal exception with > stack trace? It could just as easily be converted to a normal exception. > If FastNoSuchElementException is being used for control flow then probably it > shouldn't. Code should check hasNext rather than trying for next and dealing > with an exceptional result. I'm not sure what the current state of things are > in the JVM but at least in the past try catch blocks would inhibit > optimization even without stack traces so this type of code was considered an > antipattern. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (TINKERPOP-887) FastNoSuchElementException hides stack trace in client code
[ https://issues.apache.org/jira/browse/TINKERPOP-887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryn Cooke reopened TINKERPOP-887: -- Please could you take a look at the PR and see if it has any potential? It adds a new strategy that appends a final step to top level traversals that converts any FastNoSuchElementException in to a regular NoSuchElementException. It means that we don't get the stack trace in to the traversal, but clients do get information about where in their code the exception was thrown. > FastNoSuchElementException hides stack trace in client code > --- > > Key: TINKERPOP-887 > URL: https://issues.apache.org/jira/browse/TINKERPOP-887 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.0.2-incubating >Reporter: Bryn Cooke >Assignee: Marko A. Rodriguez >Priority: Minor > > I wrote some code that incorrectly assumed that a Gremlin query would return > an element, but it didn't. The surprise was that I got no stack trace and > therefore had no idea where in *my* code I had introduced the error. > I haven't looked in detail at the TP code, so what comes next is speculation: > If FastNoSuchElementException is being used in truly exceptional > circumstances then why is a singleton is used over a normal exception with > stack trace? It could just as easily be converted to a normal exception. > If FastNoSuchElementException is being used for control flow then probably it > shouldn't. Code should check hasNext rather than trying for next and dealing > with an exceptional result. I'm not sure what the current state of things are > in the JVM but at least in the past try catch blocks would inhibit > optimization even without stack traces so this type of code was considered an > antipattern. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1415) Vertex programs that rely on getting path parameters can't work
[ https://issues.apache.org/jira/browse/TINKERPOP-1415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15436848#comment-15436848 ] Bryn Cooke commented on TINKERPOP-1415: --- Closed, but just want to throw in the idea that PathRetractionStrategy could pick up the specific variables that are required rather than globally disabling path retraction. > Vertex programs that rely on getting path parameters can't work > --- > > Key: TINKERPOP-1415 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1415 > Project: TinkerPop > Issue Type: Bug > Components: process >Affects Versions: 3.2.1 >Reporter: Bryn Cooke > > Recently some of our vertex programs have started failing. > They rely of being able to retrieve an element out of the path. > However, whereas this used to work now the path element isn't there anymore. > The root cause is that path retraction doesn't know that the vertex program > is interested in the path and therefore culls out parameter. > I can understand why it does this, but there seems to be no way of exposing > the vertex program path requirements such that PathRetractionStrategy can > pick them up and do the right thing. > I tried hacking together a solution by making ProgramVertexProgramStep > implement Scoping. This did fix the issue, but I am not confident that this > is the way to go. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TINKERPOP-1415) Vertex programs that rely on getting path parameters can't work
[ https://issues.apache.org/jira/browse/TINKERPOP-1415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryn Cooke resolved TINKERPOP-1415. --- Resolution: Duplicate > Vertex programs that rely on getting path parameters can't work > --- > > Key: TINKERPOP-1415 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1415 > Project: TinkerPop > Issue Type: Bug > Components: process >Affects Versions: 3.2.1 >Reporter: Bryn Cooke > > Recently some of our vertex programs have started failing. > They rely of being able to retrieve an element out of the path. > However, whereas this used to work now the path element isn't there anymore. > The root cause is that path retraction doesn't know that the vertex program > is interested in the path and therefore culls out parameter. > I can understand why it does this, but there seems to be no way of exposing > the vertex program path requirements such that PathRetractionStrategy can > pick them up and do the right thing. > I tried hacking together a solution by making ProgramVertexProgramStep > implement Scoping. This did fix the issue, but I am not confident that this > is the way to go. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TINKERPOP-1415) Vertex programs that rely on getting path parameters can't work
Bryn Cooke created TINKERPOP-1415: - Summary: Vertex programs that rely on getting path parameters can't work Key: TINKERPOP-1415 URL: https://issues.apache.org/jira/browse/TINKERPOP-1415 Project: TinkerPop Issue Type: Bug Components: process Affects Versions: 3.2.1 Reporter: Bryn Cooke Recently some of our vertex programs have started failing. They rely of being able to retrieve an element out of the path. However, whereas this used to work now the path element isn't there anymore. The root cause is that path retraction doesn't know that the vertex program is interested in the path and therefore culls out parameter. I can understand why it does this, but there seems to be no way of exposing the vertex program path requirements such that PathRetractionStrategy can pick them up and do the right thing. I tried hacking together a solution by making ProgramVertexProgramStep implement Scoping. This did fix the issue, but I am not confident that this is the way to go. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1413) PropertiesTest#g_V_hasXageX_propertiesXnameX assumes that ids are longs
[
https://issues.apache.org/jira/browse/TINKERPOP-1413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15430944#comment-15430944
]
Bryn Cooke commented on TINKERPOP-1413:
---
I don't understand why the IDs need to be compared as longs. Why are the IDs
not compared using equals?
> PropertiesTest#g_V_hasXageX_propertiesXnameX assumes that ids are longs
> ---
>
> Key: TINKERPOP-1413
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1413
> Project: TinkerPop
> Issue Type: Test
> Components: process
>Reporter: Bryn Cooke
>
> This assert assumes that Ids are longs.
> {noformat}
> assertEquals(Long.valueOf(convertToVertex(graph,
> vertexProperty.value()).properties("name").next().id().toString()),
> Long.valueOf(vertexProperty.id().toString()));
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TINKERPOP-1402) Impossible for graph implementations to provide a class resolver for Gryo IO
[
https://issues.apache.org/jira/browse/TINKERPOP-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15413578#comment-15413578
]
Bryn Cooke edited comment on TINKERPOP-1402 at 8/9/16 2:19 PM:
---
I like the onMapper idea and also agree the registry method is redundant.
Trying to unify the serialization apis would seem to be a pretty tall order,
onMapper gives implementations the required flexibility. I think that the
registry method should be deprecated.
was (Author: bryncooke):
I like the onMapper idea and also agree the registry method is redundant.
Trying to unify the serialization apis would seem to be a pretty tall order,
onMapper gives implementations the required flexibility. I think that the
registry should be deprecated.
> Impossible for graph implementations to provide a class resolver for Gryo IO
>
>
> Key: TINKERPOP-1402
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1402
> Project: TinkerPop
> Issue Type: Improvement
> Components: structure
>Affects Versions: 3.2.1
>Reporter: Bryn Cooke
>Priority: Critical
>
> As far as I can tell there is no way for a graph implementation to specify a
> classresolver for the following code:
> {noformat}g.io(IoCore.gryo()).writer().create(){noformat}
> The problem is that inside the graph implementation we need to be able to do
> this:
> {noformat}
> public I io(final Io.Builder builder) {
> Io io =
> builder.graph(this).registry(MyRegistry.INSTANCE).classResolver(MyClassReolver.INSTANCE).create();
> {noformat}
> but only supplying a registry is supported.
> Other solutions could be to design GryoIo for extension so that it can be
> wrapped or to change the signature of Graph#io to:
> {noformat}
> public default Io io(final Io.Builder builder)
> {noformat}
> I would probably go for the signature change, so the graph is responsible for
> deciding the implementation that is returned.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1402) Impossible for graph implementations to provide a class resolver for Gryo IO
[
https://issues.apache.org/jira/browse/TINKERPOP-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15413578#comment-15413578
]
Bryn Cooke commented on TINKERPOP-1402:
---
I like the onMapper idea and also agree the registry method is redundant.
Trying to unify the serialization apis would seem to be a pretty tall order,
onMapper gives implementations the required flexibility. I think that the
registry should be deprecated.
> Impossible for graph implementations to provide a class resolver for Gryo IO
>
>
> Key: TINKERPOP-1402
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1402
> Project: TinkerPop
> Issue Type: Improvement
> Components: structure
>Affects Versions: 3.2.1
>Reporter: Bryn Cooke
>Priority: Critical
>
> As far as I can tell there is no way for a graph implementation to specify a
> classresolver for the following code:
> {noformat}g.io(IoCore.gryo()).writer().create(){noformat}
> The problem is that inside the graph implementation we need to be able to do
> this:
> {noformat}
> public I io(final Io.Builder builder) {
> Io io =
> builder.graph(this).registry(MyRegistry.INSTANCE).classResolver(MyClassReolver.INSTANCE).create();
> {noformat}
> but only supplying a registry is supported.
> Other solutions could be to design GryoIo for extension so that it can be
> wrapped or to change the signature of Graph#io to:
> {noformat}
> public default Io io(final Io.Builder builder)
> {noformat}
> I would probably go for the signature change, so the graph is responsible for
> deciding the implementation that is returned.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TINKERPOP-1402) Impossible for graph implementations to provide a class resolver for Gryo IO
[
https://issues.apache.org/jira/browse/TINKERPOP-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryn Cooke updated TINKERPOP-1402:
--
Summary: Impossible for graph implementations to provide a class resolver
for Gryo IO (was: Impossible for graph implementations to provide a class
resolver for IO)
> Impossible for graph implementations to provide a class resolver for Gryo IO
>
>
> Key: TINKERPOP-1402
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1402
> Project: TinkerPop
> Issue Type: Bug
> Components: structure
>Reporter: Bryn Cooke
>Priority: Critical
>
> As far as I can tell there is no way for a graph implementation to specify a
> classresolver for the following code:
> {noformat}g.io(IoCore.gryo()).writer().create(){noformat}
> The problem is that inside the graph implementation we need to be able to do
> this:
> {noformat}
> public I io(final Io.Builder builder) {
> Io io =
> builder.graph(this).registry(MyRegistry.INSTANCE).classResolver(MyClassReolver.INSTANCE).create();
> {noformat}
> but only supplying a registry is supported.
> Other solutions could be to design GryoIo for extension so that it can be
> wrapped or to change the signature of Graph#io to:
> {noformat}
> public default Io io(final Io.Builder builder)
> {noformat}
> I would probably go for the signature change, so the graph is responsible for
> deciding the implementation that is returned.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TINKERPOP-1402) Impossible for graph implementations to provide a class resolver for IO
Bryn Cooke created TINKERPOP-1402:
-
Summary: Impossible for graph implementations to provide a class
resolver for IO
Key: TINKERPOP-1402
URL: https://issues.apache.org/jira/browse/TINKERPOP-1402
Project: TinkerPop
Issue Type: Bug
Components: structure
Reporter: Bryn Cooke
Priority: Critical
As far as I can tell there is no way for a graph implementation to specify a
classresolver for the following code:
{noformat}g.io(IoCore.gryo()).writer().create(){noformat}
The problem is that inside the graph implementation we need to be able to do
this:
{noformat}
public I io(final Io.Builder builder) {
Io io =
builder.graph(this).registry(MyRegistry.INSTANCE).classResolver(MyClassReolver.INSTANCE).create();
{noformat}
but only supplying a registry is supported.
Other solutions could be to design GryoIo for extension so that it can be
wrapped or to change the signature of Graph#io to:
{noformat}
public default Io io(final Io.Builder builder)
{noformat}
I would probably go for the signature change, so the graph is responsible for
deciding the implementation that is returned.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (TINKERPOP-1355) Design HasContainer for extension
[
https://issues.apache.org/jira/browse/TINKERPOP-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryn Cooke updated TINKERPOP-1355:
--
Comment: was deleted
(was: https://github.com/apache/tinkerpop/pull/355)
> Design HasContainer for extension
> -
>
> Key: TINKERPOP-1355
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1355
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.0-incubating
>Reporter: Bryn Cooke
>Priority: Critical
>
> Currently HasContainer is final. This means that Graph implementations cannot
> support their own type systems across the entire traversal.
> Given the traversal:
> g.V.has('foo', nonTinkerpopType).out('bar').has('foo', nonTinkerpopType)
> Say that the initial traversal g.V.has('foo', nonTinkerpopType) is dealt with
> via strategy, the non-Tinkerpop type can be dealt with. However the rest of
> the traversal is processed via the default Tinkerpop pipeline, and as such it
> doesn't know how to deal with type conversions/comparisons etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1355) Design HasContainer for extension
[
https://issues.apache.org/jira/browse/TINKERPOP-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15361098#comment-15361098
]
Bryn Cooke commented on TINKERPOP-1355:
---
https://github.com/apache/tinkerpop/pull/355
> Design HasContainer for extension
> -
>
> Key: TINKERPOP-1355
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1355
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.0-incubating
>Reporter: Bryn Cooke
>Priority: Critical
>
> Currently HasContainer is final. This means that Graph implementations cannot
> support their own type systems across the entire traversal.
> Given the traversal:
> g.V.has('foo', nonTinkerpopType).out('bar').has('foo', nonTinkerpopType)
> Say that the initial traversal g.V.has('foo', nonTinkerpopType) is dealt with
> via strategy, the non-Tinkerpop type can be dealt with. However the rest of
> the traversal is processed via the default Tinkerpop pipeline, and as such it
> doesn't know how to deal with type conversions/comparisons etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TINKERPOP-1355) Design HasContainer for extension
Bryn Cooke created TINKERPOP-1355:
-
Summary: Design HasContainer for extension
Key: TINKERPOP-1355
URL: https://issues.apache.org/jira/browse/TINKERPOP-1355
Project: TinkerPop
Issue Type: Improvement
Components: process
Affects Versions: 3.2.0-incubating
Reporter: Bryn Cooke
Priority: Critical
Currently HasContainer is final. This means that Graph implementations cannot
support their own type systems across the entire traversal.
Given the traversal:
g.V.has('foo', nonTinkerpopType).out('bar').has('foo', nonTinkerpopType)
Say that the initial traversal g.V.has('foo', nonTinkerpopType) is dealt with
via strategy, the non-Tinkerpop type can be dealt with. However the rest of the
traversal is processed via the default Tinkerpop pipeline, and as such it
doesn't know how to deal with type conversions/comparisons etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TINKERPOP-1348) TraversalInterruptionTest success dependent on iteration order
[ https://issues.apache.org/jira/browse/TINKERPOP-1348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryn Cooke updated TINKERPOP-1348: -- Affects Version/s: (was: 3.1.2-incubating) 3.2.0-incubating > TraversalInterruptionTest success dependent on iteration order > -- > > Key: TINKERPOP-1348 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1348 > Project: TinkerPop > Issue Type: Test > Components: test-suite >Affects Versions: 3.2.0-incubating >Reporter: Bryn Cooke >Priority: Minor > > If the first element encountered does not fulfil the second part of the > iteration it will encounter the sleep before the iteration started check. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TINKERPOP-1348) TraversalInterruptionTest success dependent on iteration order
Bryn Cooke created TINKERPOP-1348: - Summary: TraversalInterruptionTest success dependent on iteration order Key: TINKERPOP-1348 URL: https://issues.apache.org/jira/browse/TINKERPOP-1348 Project: TinkerPop Issue Type: Test Components: test-suite Affects Versions: 3.1.2-incubating Reporter: Bryn Cooke Priority: Minor If the first element encountered does not fulfil the second part of the iteration it will encounter the sleep before the iteration started check. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
