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 >> >>> > > >> >>> > >> >>> >> >> >> >
