Hi all, Quick update as I've begun implementing the rest of the string manipulation functions, after the code freeze was lifted. Moving forward I will keep all string functions consistent with concat() in terms of not implementing scopes at this point, as these functions simply extend the ScalarMap class. If anyone feels strongly that we should add scopes, I will create a JIRA to track the request.
Cheers, Yang On Fri, Jul 7, 2023 at 8:21 AM Yang Xia <ya...@bitquilltech.com> wrote: > Hi all, > > As per last email, I've implemented the string concat() function without > "scope" and updated the documentation accordingly. Please feel free to > review the PR here https://github.com/apache/tinkerpop/pull/2099. Thanks! > > Cheers, > > Yang > > On Tue, Jun 27, 2023 at 5:43 PM Yang Xia <ya...@bitquilltech.com> wrote: > >> Hi all, >> >> As I'm starting to implement the string concat() function and looking >> at the step logic, I feel that the use of "scope" as outlined in the >> proposal ( >> https://github.com/apache/tinkerpop/blob/master/docs/src/dev/future/proposal-3-remove-closures.asciidoc#concat) >> does not quite fit with the existing definition of scope in TinkerPop. >> >> As concat is a scalar map step, there is very little differentiation >> between local and global scopes (unlike number operations with sum, mean, >> etc). The only real difference is that the local concat will also accept a >> list of strings from incoming traversers, which I don't see as particularly >> useful. I believe the best way forward is to remove scopes from concat >> entirely and only have a single ScalarMapStep implementation of concat, for >> simplicity both in implementation and usage. >> >> Examples of how this single step would behave: >> g.inject(['this', 'is', 'a', 'test']).concat() >> ==>illegal argument >> >> g.inject('this', 'is', 'a', 'test').concat() >> ==>this >> ==>is >> ==>a >> ==>test >> >> g.inject('this', 'is', 'a', 'test').concat(" a", "b") >> ==>this ab >> ==>is ab >> ==>a ab >> ==>test ab >> >> We would also have the flexibility of adding the "scope" option if use >> cases or user requests surface in the future, as opposed to trying to >> deprecate something that turns out to be not useful. >> >> Also to note that, by extension, the concept of "scope" may not apply to >> string manipulation functions in general, but this may remain to be >> discussed as we implement the rest of the functions. >> >> Any thoughts or suggestions? >> >> Cheers, >> >> Yang >> >> On Thu, Mar 2, 2023 at 4:10 PM David Bechberger <d...@bechberger.com> >> wrote: >> >>> Thanks to everyone who provided feedback so far. Are there any other >>> comments? If not, then I'd like to get this merged in this week, so we >>> can >>> get started with implementation. >>> >>> Dave >>> >>> On Mon, Feb 27, 2023 at 8:31 PM Dave Bechberger <d...@bechberger.com> >>> wrote: >>> >>> > Thanks to everyone who gave feedback so far. Any other comments on this >>> > proposal? >>> > >>> > I’d like to get this merged in this week so we can get started with >>> > implementation. >>> > >>> > Dave Bechberger >>> > >>> > >>> > On Feb 17, 2023, at 7:18 AM, David Bechberger <d...@bechberger.com> >>> wrote: >>> > >>> > >>> > I was two fast on my reply before as I did have a question for you >>> > Valentyn on this statement: >>> > >>> > >>> > *I would propose to consider adding `startWith`, `endWith` andmaybe >>> > `contains` string functions.* >>> > >>> > How would you see these steps being used differently than the current >>> > predicates? >>> > >>> > i.e. P.startingWith()/endingWith()/containing() >>> > >>> > Dave >>> > >>> > On Fri, Feb 17, 2023 at 7:12 AM David Bechberger <d...@bechberger.com> >>> > wrote: >>> > >>> >> Thank you for the fixes Valentyn, I've incorporated that PR. >>> >> >>> >> The list I proposed here was a minimum number of functions, so we can >>> >> definitely see what it would take to include something like a string >>> >> formatting function. >>> >> >>> >> Dave >>> >> >>> >> On Thu, Feb 16, 2023 at 8:36 AM Valentyn Kahamlyk >>> >> <valent...@bitquilltech.com.invalid> wrote: >>> >> >>> >>> Hi, >>> >>> >>> >>> Dave, thank you for the detailed proposal! >>> >>> >>> >>> I made small PR with naming fixes: >>> >>> https://github.com/apache/tinkerpop/pull/1973, please take a look. >>> >>> >>> >>> Also I would propose to consider adding `startWith`, `endWith` and >>> >>> maybe `contains` string functions. >>> >>> >>> >>> Another interesting feature to keep in mind is string formatting. >>> >>> for example >>> >>> `g.V(1).values('first_name').concat(' >>> ').concat(V(1).values('last_name')` >>> >>> can be simplified as >>> >>> `g.V(1).asString('%s %s', values('first_name'), values('last_name'))` >>> >>> >>> >>> Regards, Valentyn >>> >>> >>> >>> >>> >>> On Tue, Feb 14, 2023 at 8:47 AM David Bechberger < >>> d...@bechberger.com> >>> >>> wrote: >>> >>> >>> >>> > My apologies, I just saw that I didn't include a link in that >>> email. >>> >>> The >>> >>> > proposal is here: >>> >>> > >>> >>> > >>> >>> > >>> >>> >>> https://github.com/apache/tinkerpop/blob/proposal_3/docs/src/dev/future/proposal-3-remove-closures.asciidoc >>> >>> > >>> >>> > Dave >>> >>> > >>> >>> > On Tue, Feb 14, 2023 at 7:09 AM David Bechberger < >>> d...@bechberger.com> >>> >>> > wrote: >>> >>> > >>> >>> > > Hi All, >>> >>> > > >>> >>> > > There are a number of useful operations that Gremlin users often >>> >>> wish to >>> >>> > > perform that are not provided today in the form of traversal >>> steps or >>> >>> > > predicates (P/TextP). For historical reasons these functions were >>> >>> omitted >>> >>> > > and users were able to accomplish these tasks by specifying >>> anonymous >>> >>> > code >>> >>> > > blocks or “closures” to perform these tasks. For example, below >>> is an >>> >>> > > example of how you can achieve a case-insensitive search for any >>> >>> cities >>> >>> > > that contain “Miami”. >>> >>> > > >>> >>> > > g.V().hasLabel('city'). >>> >>> > > >>> >>> > > >>> >>> > >>> >>> >>> has('name',filter{it.get().toLowerCase().contains('Miami'.toLowerCase())}) >>> >>> > > >>> >>> > > While this is a powerful fallback mechanism in Gremlin to handle >>> use >>> >>> > cases >>> >>> > > where there is no functionality within the Gremlin language to >>> meet >>> >>> the >>> >>> > > requirements. However, for a variety of reasons such as security >>> and >>> >>> > > performance, many/most remote providers of TinkerPop do not allow >>> >>> users >>> >>> > to >>> >>> > > execute closures as part of a query. This leaves users with a >>> >>> problem, as >>> >>> > > the mechanism provided to solve these sorts of use cases is not >>> >>> allowed. >>> >>> > I >>> >>> > > have come up with a proposed framework for removing the need for >>> >>> closures >>> >>> > > by adding the most commonly requested functions as new Gremlin >>> steps. >>> >>> > > Below is a proposal to highlight this and propose a first set of >>> >>> these >>> >>> > > steps for string manipulation, list manipulation, and data >>> >>> manipulation. >>> >>> > > >>> >>> > > What are your thoughts on this approach? >>> >>> > > Any items we missed? >>> >>> > > Concerns? >>> >>> > > >>> >>> > > Thanks, >>> >>> > > Dave >>> >>> > > >>> >>> > >>> >>> >>> >> >>> >>
