Re: [DISCUSS] GLV Test Suite
I've been away for a few days on vacation, but before I left, I made some
pretty decent progress on the remaining tests and I'm finding less and less
of my time being focused on the test logic and more and more of it on the
translation of the tests themselves. I'm starting to feel comfortable that
most of the remaining pain is in test translation which means I could
probably issue the PR for what I have sooner than later. I'll probably just
make sure that I have at least a "good enough" representation of tests for
each step and then issue the PR. That will allow TINKERPOP-1827 to proceed
more easily and I can work more at more relaxed pace on migrating all the
tests. Please let me know if there are any concerns with that approach.
On Tue, Nov 7, 2017 at 5:02 AM, Jorge Bay Gondra
wrote:
> I've created TINKERPOP-1827 to track the progress of the test suite runner
> for Gremlin .NET.
>
> I have a working gherkin-based runner that executes the steps (parsing
> gremlin groovy / parameters / results) as defined in the TINKERPOP-1784 WIP
> branch.
>
> https://github.com/jorgebay/tinkerpop/commits/gherkin-cs-runner
>
> I'll wait for TINKERPOP-1784 to be resolved in order the follow the last
> changes and submit a pull request for it.
>
> On Tue, Oct 31, 2017 at 11:09 AM, Jorge Bay Gondra <
> jorgebaygon...@gmail.com
> > wrote:
>
> > Ok.
> > Going back to my initial comment regarding enums: don't mind, I've
> > included the possibility to use enums on the C# parser.
> >
> > On Mon, Oct 30, 2017 at 7:15 PM, Stephen Mallette
> > wrote:
> >
> >> I guess there wouldn't be a problem with that, though having it the way
> it
> >> works now was a nice check to ensure that the ScriptEngine was
> configured
> >> properly. I guess that shouldn't be the focus on this body of tests
> >> though.
> >> We should be more concerned that the elements of the Gremlin language
> >> actually work.
> >>
> >> On Thu, Oct 26, 2017 at 8:47 AM, Jorge Bay Gondra <
> >> jorgebaygon...@gmail.com>
> >> wrote:
> >>
> >> > I see that for most languages using bytecode to native language
> >> translator
> >> > would be the easiest solution. In the case of the JavaScript GLV, it
> >> would
> >> > be fairly straightforward to implement (and I plan to do so!).
> >> > In the case of C#, being more strict regarding typing than java, it
> >> would
> >> > be an incomplete solution. For example:
> >> >
> >> > Consider the following traversal in Java: g.V().values("age")
> >> > The type parameter for values() method is inferred at runtime and
> things
> >> > "just works" thanks to type erasure.
> >> >
> >> > In the case of C#, it should be written as g.V().Values("age") ,
> >> with
> >> > the type parameter to specify which type of traverser are you
> expecting
> >> at
> >> > a compile time.
> >> >
> >> > That's why it wont be possible to make a generic translator from
> >> bytecode
> >> > to C# code, without understanding which generic types are expected.
> >> >
> >> > In the case of C#, I was going for a translator on the C# side that
> >> > tokenizes the gremlin traversal. Once the traversal is tokenized, in
> the
> >> > moment of invoking the methods (with reflection), it can be made aware
> >> of
> >> > the modern graph data (with datatypes!), ie: For method Values<>(), if
> >> the
> >> > property key is "age" -> use int as generic type parameter.
> >> >
> >> > On Thu, Oct 26, 2017 at 2:12 PM, Stephen Mallette <
> spmalle...@gmail.com
> >> >
> >> > wrote:
> >> >
> >> > > I can't help thinking that perhaps non-JVM languages need to
> leverage
> >> > > bytecode to make traversal building easier. We already have an
> >> > established
> >> > > pattern for converting bytecode into Traversals and while it is
> >> different
> >> > > for each language, it's generally governed by the Translator
> >> interface.
> >> > > Note that we already do this for Java, Groovy, and Python and the
> code
> >> > > isn't too crazy - just 200 lines or so:
> >> > >
> >> > > https://github.com/apache/tinkerpop/blob/master/gremlin-
> >> > > core/src/main/java/org/apache/tinkerpop/gremlin/jsr223/
> >> > JavaTranslator.java
> >> > > https://github.com/apache/tinkerpop/blob/master/gremlin-
> >> > > groovy/src/main/java/org/apache/tinkerpop/gremlin/groovy/jsr223/
> >> > > GroovyTranslator.java
> >> > > https://github.com/apache/tinkerpop/blob/master/gremlin-
> >> > > python/src/main/java/org/apache/tinkerpop/gremlin/python/jsr223/
> >> > > PythonTranslator.java
> >> > >
> >> > > I think that non-JVM languages could send the Gremlin string from
> the
> >> > test
> >> > > to Gremlin Server as a script first and return the bytecode as JSON.
> >> Then
> >> > > it could use a "Translator" to then parse it into it's native
> >> language.
> >> > > Shouldn't we just build a CSharpTranslator similar to these? does
> that
> >> > make
> >> > > sense?
> >> > >
> >> > >
> >> > > On Wed, Oct 25, 2017 at 11:11 AM, Jorge Bay Gondra <
> >> > > jorgebaygon...@gmail.com
> >> > > > wrote:
> >> > >
> >
Re: [DISCUSS] GLV Test Suite
Makes sense, as long as we have the basic logic nailed down for the steps /
parameters / results, we can continue adding scenarios afterwards (new
scenarios with the same step structure should work in any language).
On Wed, Nov 8, 2017 at 1:49 PM, Stephen Mallette
wrote:
> I've been away for a few days on vacation, but before I left, I made some
> pretty decent progress on the remaining tests and I'm finding less and less
> of my time being focused on the test logic and more and more of it on the
> translation of the tests themselves. I'm starting to feel comfortable that
> most of the remaining pain is in test translation which means I could
> probably issue the PR for what I have sooner than later. I'll probably just
> make sure that I have at least a "good enough" representation of tests for
> each step and then issue the PR. That will allow TINKERPOP-1827 to proceed
> more easily and I can work more at more relaxed pace on migrating all the
> tests. Please let me know if there are any concerns with that approach.
>
> On Tue, Nov 7, 2017 at 5:02 AM, Jorge Bay Gondra >
> wrote:
>
> > I've created TINKERPOP-1827 to track the progress of the test suite
> runner
> > for Gremlin .NET.
> >
> > I have a working gherkin-based runner that executes the steps (parsing
> > gremlin groovy / parameters / results) as defined in the TINKERPOP-1784
> WIP
> > branch.
> >
> > https://github.com/jorgebay/tinkerpop/commits/gherkin-cs-runner
> >
> > I'll wait for TINKERPOP-1784 to be resolved in order the follow the last
> > changes and submit a pull request for it.
> >
> > On Tue, Oct 31, 2017 at 11:09 AM, Jorge Bay Gondra <
> > jorgebaygon...@gmail.com
> > > wrote:
> >
> > > Ok.
> > > Going back to my initial comment regarding enums: don't mind, I've
> > > included the possibility to use enums on the C# parser.
> > >
> > > On Mon, Oct 30, 2017 at 7:15 PM, Stephen Mallette <
> spmalle...@gmail.com>
> > > wrote:
> > >
> > >> I guess there wouldn't be a problem with that, though having it the
> way
> > it
> > >> works now was a nice check to ensure that the ScriptEngine was
> > configured
> > >> properly. I guess that shouldn't be the focus on this body of tests
> > >> though.
> > >> We should be more concerned that the elements of the Gremlin language
> > >> actually work.
> > >>
> > >> On Thu, Oct 26, 2017 at 8:47 AM, Jorge Bay Gondra <
> > >> jorgebaygon...@gmail.com>
> > >> wrote:
> > >>
> > >> > I see that for most languages using bytecode to native language
> > >> translator
> > >> > would be the easiest solution. In the case of the JavaScript GLV, it
> > >> would
> > >> > be fairly straightforward to implement (and I plan to do so!).
> > >> > In the case of C#, being more strict regarding typing than java, it
> > >> would
> > >> > be an incomplete solution. For example:
> > >> >
> > >> > Consider the following traversal in Java: g.V().values("age")
> > >> > The type parameter for values() method is inferred at runtime and
> > things
> > >> > "just works" thanks to type erasure.
> > >> >
> > >> > In the case of C#, it should be written as
> g.V().Values("age") ,
> > >> with
> > >> > the type parameter to specify which type of traverser are you
> > expecting
> > >> at
> > >> > a compile time.
> > >> >
> > >> > That's why it wont be possible to make a generic translator from
> > >> bytecode
> > >> > to C# code, without understanding which generic types are expected.
> > >> >
> > >> > In the case of C#, I was going for a translator on the C# side that
> > >> > tokenizes the gremlin traversal. Once the traversal is tokenized, in
> > the
> > >> > moment of invoking the methods (with reflection), it can be made
> aware
> > >> of
> > >> > the modern graph data (with datatypes!), ie: For method Values<>(),
> if
> > >> the
> > >> > property key is "age" -> use int as generic type parameter.
> > >> >
> > >> > On Thu, Oct 26, 2017 at 2:12 PM, Stephen Mallette <
> > spmalle...@gmail.com
> > >> >
> > >> > wrote:
> > >> >
> > >> > > I can't help thinking that perhaps non-JVM languages need to
> > leverage
> > >> > > bytecode to make traversal building easier. We already have an
> > >> > established
> > >> > > pattern for converting bytecode into Traversals and while it is
> > >> different
> > >> > > for each language, it's generally governed by the Translator
> > >> interface.
> > >> > > Note that we already do this for Java, Groovy, and Python and the
> > code
> > >> > > isn't too crazy - just 200 lines or so:
> > >> > >
> > >> > > https://github.com/apache/tinkerpop/blob/master/gremlin-
> > >> > > core/src/main/java/org/apache/tinkerpop/gremlin/jsr223/
> > >> > JavaTranslator.java
> > >> > > https://github.com/apache/tinkerpop/blob/master/gremlin-
> > >> > > groovy/src/main/java/org/apache/tinkerpop/gremlin/groovy/jsr223/
> > >> > > GroovyTranslator.java
> > >> > > https://github.com/apache/tinkerpop/blob/master/gremlin-
> > >> > > python/src/main/java/org/apache/tinkerpop/gremlin/python/jsr223/
> > >> > > PythonTranslator.java
[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)
