You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by Ted Wilmes <tw...@gmail.com> on 2017/02/01 14:51:53 UTC
ChooseStep & count type coercion
Hello,
I wrote a traversal using a choose that included a count in the branching
traversal. Here is a simplified version:
g.V().choose(bothE().count()).option(1, constant(1)).option(3, constant(3))
I wasn't getting any results and then realized none of the options would
match because count produces a long.
This is the correct behavior now and makes sense in the context of Java's
type system but I was wondering if it
wouldn't make sense to handle the type coercion from int to long so the
user could use an integer? I think this
would be consistent with how other steps like 'is' works:
gremlin> g.V().local(bothE().count()).is(3)
==>3
==>3
==>3
Full example:
gremlin> g = TinkerFactory.createModern().traversal()
==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
gremlin> g.V().choose(bothE().count()).option(1, constant(1)).option(3,
constant(3))
gremlin> g.V().choose(bothE().count()).option(1l, constant(1)).option(3l,
constant(3))
==>3
==>1
==>3
==>3
==>1
==>1
Thanks,
Ted
Re: ChooseStep & count type coercion
Posted by Ted Wilmes <tw...@gmail.com>.
Good catch and yep, that's the one.
On Fri, Feb 17, 2017 at 9:14 AM, Robert Dale <ro...@gmail.com> wrote:
> I think this is the correct link
> https://issues.apache.org/jira/browse/TINKERPOP-1620
>
> Robert Dale
>
> On Wed, Feb 1, 2017 at 12:56 PM, Ted Wilmes <tw...@gmail.com> wrote:
>
> > Thanks guys. Ticket created:
> > https://issues.apache.org/jira/browse/TINKERPOP-1596
> >
> > --Ted
> >
> > On Wed, Feb 1, 2017 at 10:37 AM, Marko Rodriguez <ok...@gmail.com>
> > wrote:
> >
> > > I concur with Robert.
> > >
> > > Kuppitz has done a lot to help in this area with NumberHelper. We
> should
> > > make sure it is propagated throughout.
> > > https://github.com/apache/tinkerpop/blob/master/gremlin-
> > > core/src/main/java/org/apache/tinkerpop/gremlin/util/NumberHelper.java
> <
> > > https://github.com/apache/tinkerpop/blob/master/gremlin-
> > > core/src/main/java/org/apache/tinkerpop/gremlin/util/
> NumberHelper.java>
> > >
> > > Can you please make a ticket about your particular ChooseStep
> situation?
> > >
> > > https://issues.apache.org/jira/browse/TINKERPOP/ <
> > > https://issues.apache.org/jira/browse/TINKERPOP/?
> > > selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel>
> > >
> > > Thank you,
> > > Marko.
> > >
> > > http://markorodriguez.com
> > >
> > >
> > >
> > > > On Feb 1, 2017, at 8:03 AM, Robert Dale <ro...@gmail.com> wrote:
> > > >
> > > > It absolutely would make sense to treat numbers as numbers and not as
> > > data
> > > > structures. This is one of those things that keeps gremlin tied to a
> > > Java
> > > > implementation and from being language-agnostic.
> > > >
> > > > Robert Dale
> > > >
> > > > On Wed, Feb 1, 2017 at 9:51 AM, Ted Wilmes <tw...@gmail.com>
> wrote:
> > > >
> > > >> Hello,
> > > >> I wrote a traversal using a choose that included a count in the
> > > branching
> > > >> traversal. Here is a simplified version:
> > > >>
> > > >> g.V().choose(bothE().count()).option(1, constant(1)).option(3,
> > > >> constant(3))
> > > >>
> > > >> I wasn't getting any results and then realized none of the options
> > would
> > > >> match because count produces a long.
> > > >> This is the correct behavior now and makes sense in the context of
> > > Java's
> > > >> type system but I was wondering if it
> > > >> wouldn't make sense to handle the type coercion from int to long so
> > the
> > > >> user could use an integer? I think this
> > > >> would be consistent with how other steps like 'is' works:
> > > >>
> > > >> gremlin> g.V().local(bothE().count()).is(3)
> > > >> ==>3
> > > >> ==>3
> > > >> ==>3
> > > >>
> > > >>
> > > >> Full example:
> > > >> gremlin> g = TinkerFactory.createModern().traversal()
> > > >> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> > > >> gremlin> g.V().choose(bothE().count()).option(1,
> > constant(1)).option(3,
> > > >> constant(3))
> > > >> gremlin> g.V().choose(bothE().count()).option(1l,
> > > constant(1)).option(3l,
> > > >> constant(3))
> > > >> ==>3
> > > >> ==>1
> > > >> ==>3
> > > >> ==>3
> > > >> ==>1
> > > >> ==>1
> > > >>
> > > >>
> > > >> Thanks,
> > > >> Ted
> > > >>
> > >
> > >
> >
>
Re: ChooseStep & count type coercion
Posted by Robert Dale <ro...@gmail.com>.
I think this is the correct link
https://issues.apache.org/jira/browse/TINKERPOP-1620
Robert Dale
On Wed, Feb 1, 2017 at 12:56 PM, Ted Wilmes <tw...@gmail.com> wrote:
> Thanks guys. Ticket created:
> https://issues.apache.org/jira/browse/TINKERPOP-1596
>
> --Ted
>
> On Wed, Feb 1, 2017 at 10:37 AM, Marko Rodriguez <ok...@gmail.com>
> wrote:
>
> > I concur with Robert.
> >
> > Kuppitz has done a lot to help in this area with NumberHelper. We should
> > make sure it is propagated throughout.
> > https://github.com/apache/tinkerpop/blob/master/gremlin-
> > core/src/main/java/org/apache/tinkerpop/gremlin/util/NumberHelper.java <
> > https://github.com/apache/tinkerpop/blob/master/gremlin-
> > core/src/main/java/org/apache/tinkerpop/gremlin/util/NumberHelper.java>
> >
> > Can you please make a ticket about your particular ChooseStep situation?
> >
> > https://issues.apache.org/jira/browse/TINKERPOP/ <
> > https://issues.apache.org/jira/browse/TINKERPOP/?
> > selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel>
> >
> > Thank you,
> > Marko.
> >
> > http://markorodriguez.com
> >
> >
> >
> > > On Feb 1, 2017, at 8:03 AM, Robert Dale <ro...@gmail.com> wrote:
> > >
> > > It absolutely would make sense to treat numbers as numbers and not as
> > data
> > > structures. This is one of those things that keeps gremlin tied to a
> > Java
> > > implementation and from being language-agnostic.
> > >
> > > Robert Dale
> > >
> > > On Wed, Feb 1, 2017 at 9:51 AM, Ted Wilmes <tw...@gmail.com> wrote:
> > >
> > >> Hello,
> > >> I wrote a traversal using a choose that included a count in the
> > branching
> > >> traversal. Here is a simplified version:
> > >>
> > >> g.V().choose(bothE().count()).option(1, constant(1)).option(3,
> > >> constant(3))
> > >>
> > >> I wasn't getting any results and then realized none of the options
> would
> > >> match because count produces a long.
> > >> This is the correct behavior now and makes sense in the context of
> > Java's
> > >> type system but I was wondering if it
> > >> wouldn't make sense to handle the type coercion from int to long so
> the
> > >> user could use an integer? I think this
> > >> would be consistent with how other steps like 'is' works:
> > >>
> > >> gremlin> g.V().local(bothE().count()).is(3)
> > >> ==>3
> > >> ==>3
> > >> ==>3
> > >>
> > >>
> > >> Full example:
> > >> gremlin> g = TinkerFactory.createModern().traversal()
> > >> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> > >> gremlin> g.V().choose(bothE().count()).option(1,
> constant(1)).option(3,
> > >> constant(3))
> > >> gremlin> g.V().choose(bothE().count()).option(1l,
> > constant(1)).option(3l,
> > >> constant(3))
> > >> ==>3
> > >> ==>1
> > >> ==>3
> > >> ==>3
> > >> ==>1
> > >> ==>1
> > >>
> > >>
> > >> Thanks,
> > >> Ted
> > >>
> >
> >
>
Re: ChooseStep & count type coercion
Posted by Ted Wilmes <tw...@gmail.com>.
Thanks guys. Ticket created:
https://issues.apache.org/jira/browse/TINKERPOP-1596
--Ted
On Wed, Feb 1, 2017 at 10:37 AM, Marko Rodriguez <ok...@gmail.com>
wrote:
> I concur with Robert.
>
> Kuppitz has done a lot to help in this area with NumberHelper. We should
> make sure it is propagated throughout.
> https://github.com/apache/tinkerpop/blob/master/gremlin-
> core/src/main/java/org/apache/tinkerpop/gremlin/util/NumberHelper.java <
> https://github.com/apache/tinkerpop/blob/master/gremlin-
> core/src/main/java/org/apache/tinkerpop/gremlin/util/NumberHelper.java>
>
> Can you please make a ticket about your particular ChooseStep situation?
>
> https://issues.apache.org/jira/browse/TINKERPOP/ <
> https://issues.apache.org/jira/browse/TINKERPOP/?
> selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel>
>
> Thank you,
> Marko.
>
> http://markorodriguez.com
>
>
>
> > On Feb 1, 2017, at 8:03 AM, Robert Dale <ro...@gmail.com> wrote:
> >
> > It absolutely would make sense to treat numbers as numbers and not as
> data
> > structures. This is one of those things that keeps gremlin tied to a
> Java
> > implementation and from being language-agnostic.
> >
> > Robert Dale
> >
> > On Wed, Feb 1, 2017 at 9:51 AM, Ted Wilmes <tw...@gmail.com> wrote:
> >
> >> Hello,
> >> I wrote a traversal using a choose that included a count in the
> branching
> >> traversal. Here is a simplified version:
> >>
> >> g.V().choose(bothE().count()).option(1, constant(1)).option(3,
> >> constant(3))
> >>
> >> I wasn't getting any results and then realized none of the options would
> >> match because count produces a long.
> >> This is the correct behavior now and makes sense in the context of
> Java's
> >> type system but I was wondering if it
> >> wouldn't make sense to handle the type coercion from int to long so the
> >> user could use an integer? I think this
> >> would be consistent with how other steps like 'is' works:
> >>
> >> gremlin> g.V().local(bothE().count()).is(3)
> >> ==>3
> >> ==>3
> >> ==>3
> >>
> >>
> >> Full example:
> >> gremlin> g = TinkerFactory.createModern().traversal()
> >> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> >> gremlin> g.V().choose(bothE().count()).option(1, constant(1)).option(3,
> >> constant(3))
> >> gremlin> g.V().choose(bothE().count()).option(1l,
> constant(1)).option(3l,
> >> constant(3))
> >> ==>3
> >> ==>1
> >> ==>3
> >> ==>3
> >> ==>1
> >> ==>1
> >>
> >>
> >> Thanks,
> >> Ted
> >>
>
>
Re: ChooseStep & count type coercion
Posted by Marko Rodriguez <ok...@gmail.com>.
I concur with Robert.
Kuppitz has done a lot to help in this area with NumberHelper. We should make sure it is propagated throughout.
https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/util/NumberHelper.java <https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/util/NumberHelper.java>
Can you please make a ticket about your particular ChooseStep situation?
https://issues.apache.org/jira/browse/TINKERPOP/ <https://issues.apache.org/jira/browse/TINKERPOP/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel>
Thank you,
Marko.
http://markorodriguez.com
> On Feb 1, 2017, at 8:03 AM, Robert Dale <ro...@gmail.com> wrote:
>
> It absolutely would make sense to treat numbers as numbers and not as data
> structures. This is one of those things that keeps gremlin tied to a Java
> implementation and from being language-agnostic.
>
> Robert Dale
>
> On Wed, Feb 1, 2017 at 9:51 AM, Ted Wilmes <tw...@gmail.com> wrote:
>
>> Hello,
>> I wrote a traversal using a choose that included a count in the branching
>> traversal. Here is a simplified version:
>>
>> g.V().choose(bothE().count()).option(1, constant(1)).option(3,
>> constant(3))
>>
>> I wasn't getting any results and then realized none of the options would
>> match because count produces a long.
>> This is the correct behavior now and makes sense in the context of Java's
>> type system but I was wondering if it
>> wouldn't make sense to handle the type coercion from int to long so the
>> user could use an integer? I think this
>> would be consistent with how other steps like 'is' works:
>>
>> gremlin> g.V().local(bothE().count()).is(3)
>> ==>3
>> ==>3
>> ==>3
>>
>>
>> Full example:
>> gremlin> g = TinkerFactory.createModern().traversal()
>> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
>> gremlin> g.V().choose(bothE().count()).option(1, constant(1)).option(3,
>> constant(3))
>> gremlin> g.V().choose(bothE().count()).option(1l, constant(1)).option(3l,
>> constant(3))
>> ==>3
>> ==>1
>> ==>3
>> ==>3
>> ==>1
>> ==>1
>>
>>
>> Thanks,
>> Ted
>>
Re: ChooseStep & count type coercion
Posted by Robert Dale <ro...@gmail.com>.
It absolutely would make sense to treat numbers as numbers and not as data
structures. This is one of those things that keeps gremlin tied to a Java
implementation and from being language-agnostic.
Robert Dale
On Wed, Feb 1, 2017 at 9:51 AM, Ted Wilmes <tw...@gmail.com> wrote:
> Hello,
> I wrote a traversal using a choose that included a count in the branching
> traversal. Here is a simplified version:
>
> g.V().choose(bothE().count()).option(1, constant(1)).option(3,
> constant(3))
>
> I wasn't getting any results and then realized none of the options would
> match because count produces a long.
> This is the correct behavior now and makes sense in the context of Java's
> type system but I was wondering if it
> wouldn't make sense to handle the type coercion from int to long so the
> user could use an integer? I think this
> would be consistent with how other steps like 'is' works:
>
> gremlin> g.V().local(bothE().count()).is(3)
> ==>3
> ==>3
> ==>3
>
>
> Full example:
> gremlin> g = TinkerFactory.createModern().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> g.V().choose(bothE().count()).option(1, constant(1)).option(3,
> constant(3))
> gremlin> g.V().choose(bothE().count()).option(1l, constant(1)).option(3l,
> constant(3))
> ==>3
> ==>1
> ==>3
> ==>3
> ==>1
> ==>1
>
>
> Thanks,
> Ted
>