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