I also like that Rob's proposed extensions API translates well across a client-server barrier, whereas my proposal references specific Java classes directly. We could go the URI route or the Java package name route, since both have widely accepted conventions for partitioning the global namespace.
On Thu, Aug 20, 2015 at 1:43 PM, Rob Vesse <[email protected]> wrote: > You could do something akin to the SPARQL approach > > You specify some limited subset of known functions with well defined > semantics e.g. contains(), startsWith() etc that are implemented in the > core language and then define a mechanism via which extension functions > may be referenced > > e.g. > > g.V().has('name', Functions.contains('monkey')) > > And > > g.V().has('name', Functions.extension('http://acme/textSearch', 'monkey')) > > The idea being that extension takes the name of the function and then zero > or more arguments which are interpreted by the specific vendor > implementation of that extension function > > In SPARQL those are named via URIs and each implementation can choose what > extension function(s) they add to their core implementation, in principal > at least having a global namespace allows for common useful extension > functions to be defined by one vendor and adopted by other vendors over > time. For Gremlim you may want to use some other naming scheme though > URIs have the advantage that you can take advantage of common conventions > around domain and thus namespace ownership > > Rob > > On 20/08/2015 12:36, "Matt Frantz" <[email protected]> wrote: > > >I agree that there is a set of operations on scalar types that should be > >supported efficiently (i.e. by pushing them down). It would be nice if we > >could figure out a way to exploit vendor-specific features in some > >extensible portion of the API. Otherwise, we're just aiming at least > >common denominator capabilities. > > > >Many operations have standard definitions, but something like regular > >expressions can have variants, so we must be clear about how we would > >define conforming implementations. > > > >Suppose vendor Acme has an exclusive text searching capability that > >includes case folding, stemming, synonym matching, spelling correction, > >camel-case splittings, etc. Could there be an API like "P" that could be > >provided by the vendor, so that Gremlin expressions would reference it? > >Otherwise, we end up either maintaining a universal catalog of vendor > >capabilities or fuzzy matching the vendor capabilities to a universal > >list, > >which leads to vendor-specific application behavior. We could then > >migrate > >capabilities into the core as they become more widespread. > > > >g.V().has('name', AcmeP.exclusiveTextSearch('monkey')); > > > >As an application writer, I want to know when I can expect vendor-specific > >behavior, and this sort of API design would remind me of such choices. > > > > > >On Thu, Aug 20, 2015 at 11:17 AM, pieter <[email protected]> wrote: > > > >> Hi, > >> > >> I view Gremlin as a first class query language. As such it is more > >> concerned with what than how. > >> > >> I reckon > >> > >> String.contains > >> String.startsWith > >> String.endsWith > >> and some form of regular expression > >> > >> is so common it would be expected for any query language. > >> > >> A quick check on neo4j cypher and orientdb sql both support the above. > >> Cypher also has a case sensitive toggle/expression. Not sure about > >> Orientdb, probably a 'upper() + like %' > >> > >> The above predicates have no need for an index. If an index can be used > >> all the better but either way it should work. > >> > >> Thanks > >> Pieter > >> > >> > >> On 17/08/2015 16:10, Daniel Kuppitz wrote: > >> > >>> See: [TinkerPop3] Blueprints3 -- Push Down Predicates All Up in Yo' > >>>Face > >>> > >>><https://groups.google.com/d/msg/gremlin-users/ls4FD5r43Iw/AIFFCMyi3EQJ > > > >>> > >>> On Mon, Aug 17, 2015 at 4:08 PM, Daniel Kuppitz <[email protected]> > >>>wrote: > >>> > >>> Because every vendor handles text comparisons differently. Some allow > >>>> regular expressions, others don't. Some vendors do case-sensitive > >>>> matches, > >>>> others case-insensitive, etc. > >>>> > >>>> Cheers, > >>>> Daniel > >>>> > >>>> > >>>> On Mon, Aug 17, 2015 at 12:55 PM, Stephen Mallette > >>>><[email protected] > >>>> > > >>>> wrote: > >>>> > >>>> I don't remember why we didn't have predicates for "text" searches? > >>>>> Marko, > >>>>> do you remember? > >>>>> > >>>>> On Tue, Aug 11, 2015 at 3:35 PM, pieter <[email protected]> > >>>>> wrote: > >>>>> > >>>>> Hi, > >>>>>> > >>>>>> Going through the gremlin Predicates I do not see one that is for > >>>>>>doing > >>>>>> full text searches. > >>>>>> Have I missed it or is omitted on purpose? > >>>>>> > >>>>>> Having both case sensitive and non case-sensitive searches is a > >>>>>>common > >>>>>> requirement. > >>>>>> > >>>>>> Thanks > >>>>>> Pieter > >>>>>> > >>>>>> > >>>> > >> > > > > >
