Hi Marko,
I think it makes a lot of sense to bring some math()-step inspiration into many
of these string manipulation functions. I believe that would work particularly
well for something like the format()-step that Valentyn proposed earlier. We
would need to invent some syntax for including labels and the ‘_` variable in
the format string but that’s not a major issue.
I imagine this looking something like this:
gremlin> g.V().as("a").out("created").format(“%sa; created
%s_;”).by(“name”).by(“name”)
==>marko created lop
==>josh created ripple
==>josh created lop
==>peter created lop
gremlin> g.V().hasLabel(“person”).format(“%s_; has age
%03d_;”).by(“name”).by(“age”)
==>marko has age 029
==>vadas has age 027
==>josh has age 032
==>peter has age 035
gremlin> g.V().hasLabel(“person”).format(“%s_; knows %d_; other
people”).by(“name”).by(out(“knows”).count())
==>marko knows 2 other people
==>vadas knows 0 other people
==>josh knows 0 other people
==>peter knows 0 other people
If we were to have a step with this sort of functionality I think it would
negate the need for a more capable concat()-step and we would be best served
keeping concat() as simple as possible.
Regards,
Cole
From: Marko Rodriguez <okramma...@gmail.com>
Date: Wednesday, August 16, 2023 at 6:59 AM
To: dev@tinkerpop.apache.org <dev@tinkerpop.apache.org>
Subject: Re: Thoughts on the new concat() step
You guys are ruining the language with your approach to string manipulation.
Look to math()-step to see how you should handle non-graph data structure
manipulations.
Marko.
> On Aug 16, 2023, at 4:35 AM, Stephen Mallette <spmalle...@gmail.com> wrote:
>
> I think the syntax should just be changed from concat(Traversal) to
> concat(Traversal...) which would let you work around this issue by using
> constant():
>
> g.V(3).as('a').values('code').concat(constant(' is in '),
> select('a').values('city'))
>
> This would address the symmetry problem with concat(String...) without
> having to open up concat(Object...) (at least not yet). I think format()
> could be a neat step and there was an open issue for it at one point:
>
> https://issues.apache.org/jira/browse/TINKERPOP-2334
>
> i'd closed it once i saw that dave had suggested these lower level string
> functions. i'd like to see the lower level functions added first and then
> talk about bringing back to the format() idea.
>
> On Tue, Aug 15, 2023 at 7:54 PM Valentyn Kahamlyk
> <valent...@bitquilltech.com.invalid> wrote:
>
>> Maybe for such situations it is more organic to add a new `format` step?
>> It will also be very useful in many other situations and be able to replace
>> the asString step.
>> ```
>> g.V(3).format("%s is in %s", values("code", "city")))
>> ```
>>
>> or other example for modern graph
>> ```
>> g.V().hasLabel("person").format("Person %s is %s years old", values("name",
>> "age"))
>> ```
>>
>> On Tue, Aug 15, 2023 at 8:24 AM Kelvin Lawrence <
>> kelvin.r.lawre...@gmail.com>
>> wrote:
>>
>>> Playing with Gremlin 3.7, and looking at concat() I kind of wish this
>>> worked
>>>
>>> g.V(3).as('a').values('code').concat(' is in ',
>> select('a').values('city'))
>>>
>>> rather than having to do
>>>
>>> g.V(3).as('a').values('code').concat(' is in
>>> ').concat(select('a').values('city'))
>>>
>>> 2:58 <https://amzn-aws.slack.com/archives/D019DRT9KKN/p1691611095325259>
>>> we do allow
>>>
>>> g.V(3).as('a').values('code').concat(' is in ', 'Austin') //String...
>>>
>>> so it feels a little unbalanced. I wish I had noticed this before
>>> but I guess the type signature would have to be object... almost for that
>>> to work. Perhaps there is a possible compromise where we could do
>> something
>>> using Traversal... and String...
>>>
>>> --
>>> Cheers, Kelvin
>>>
>>
Warning: The sender of this message could not be validated and may not be the
actual sender.
