https://issues.apache.org/jira/browse/TINKERPOP-2041
I'm going to work on some simple predicates (startsWith, endsWith and contains). For now, I'd like to keep it really simple and only provide simple 1-arg overloads. Also, RegEx will not be included as there are still some back and forth discussions regarding different RegEx syntaxes. Cheers, Daniel On 2018/06/21 20:06:46, Stephen Mallette <[email protected]> wrote: > > Also, wouldn't you need to configure a serializer for > 'DseGraph.searchType'? > > that's the nice part of with() - internally that falls into a standard Map > in bytecode and no serialization hassles. it still leaves the graph > provider to expose a "DseGraph" type of class, but at least there is > nothing to configure anywhere > > > Then all that's left is fuzzy. I don't have an opinion on that yet. > Maybe it's more Search enums? > > could be. or with() is the catch all case that providers can use for > "everything else" they can come up with....for now > > > > On Thu, Jun 21, 2018 at 3:52 PM Robert Dale <[email protected]> wrote: > > > No, that makes it non-portable, provider-specific. That is, I can't > > cut-n-paste that from one graph db to the next. Also, wouldn't you need to > > configure a serializer for 'DseGraph.searchType'? > > > > I think we can start with a small, simple set. > > > > startsWith(String) > > startsWith(Search,String) > > contains(String) > > contains(Search, String) > > regex(String) > > regex(Search, String) > > > > Each takes Search, String. Where Search is an enum of String (default), > > Text (tokenized). String is the search term. > > > > The regex syntax may be provider-specific, but the traversal would be > > portable. If the provider doesn't override the step/predicate then it would > > use the default implementation. > > > > Then all that's left is fuzzy. I don't have an opinion on that yet. Maybe > > it's more Search enums? > > > > Robert Dale > > > > > > On Thu, Jun 21, 2018 at 3:04 PM Stephen Mallette <[email protected]> > > wrote: > > > > > Just thinking out loud here, but i wonder if we could keep our predicate > > > list more or less as-is, but then use with() to modulate a has() to be > > > provider specific: > > > > > > g.V(). > > > has('longText',eq("a.*"). > > > with(DseGraph.searchType, tokenRegex) > > > > > > In other words, this would be the standard way that users would inform > > > graph providers to handle special text search types. The upside is that > > > > > > 1. graph providers no longer have to hassle with serialization at all to > > > implement this (which means users don't need special configuration of > > their > > > servers/drivers). > > > 2. we have a common way that all graph providers can take advantage of > > and > > > thus users have one method for writing their gremlin (albeit with > > different > > > with() and search syntax). > > > 3. we can make this part of our reference implementation i think pretty > > > easily for TinkerGraph with some basic java regex stuff. > > > 4. stays backward compatible with existing graph provider predicates > > > > > > good idea? > > > > > > > > > > > > On Mon, Jun 11, 2018 at 9:12 AM Stephen Mallette <[email protected]> > > > wrote: > > > > > > > I found a CosmosDB issue on github calling for support of text > > predicates > > > > > > > > https://github.com/Azure/azure-documentdb-dotnet/issues/473 > > > > > > > > and it conveniently listed the text predicates for a number of > > different > > > > graphs, so it made the job of compiling these pretty easy. > > > > > > > > DSE Graph (tokenized search is for long multi-sentence type properties) > > > > + eq/neq > > > > + prefix > > > > + regex > > > > + token > > > > + tokenPrefix > > > > + tokenRegex > > > > + phrase > > > > + fuzzy > > > > + tokenFuzzy > > > > > > > > > > > > > > > > > https://docs.datastax.com/en/dse/6.0/dse-dev/datastax_enterprise/graph/using/useSearchIndexes.html > > > > > > > > JanusGraph > > > > + textContains > > > > + textContainsPrefix > > > > + textContainsRegex > > > > + textContainsFuzzy > > > > + eq/neq > > > > + textPrefix > > > > + textRegex > > > > + textFuzzy > > > > > > > > http://docs.janusgraph.org/latest/index-parameters.html#text-search > > > > > > > > Neo4j/Cypher > > > > + STARTS WITH > > > > + ENDS WITH > > > > + CONTAINS > > > > > > > > > > > > > http://www.jexp.de/blog/html/full-text-and-spatial-search-in-neo4j-3.html > > > > > > > > OrientDB - basically just lucene syntax > > > > + LUCENE > > > > > > > > https://orientdb.com/docs/last/Full-Text-Index.html > > > > > > > > So - that's the list as best I can determine. JanusGraph and DSE Graph > > > > have the most complex set of expressions it seems. Neo4j/Cypher has the > > > > easiest developer friendly looking set that probably covers most of the > > > > questions we get out in the community. OrientDB gets vendor specific in > > > > what they do. Did I leave any out - please update this thread if I > > did. > > > > > > > > Not sure what we do with that now, but that's what is out there. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
