> 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 <robd...@gmail.com> 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 <spmalle...@gmail.com>
> 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 <spmalle...@gmail.com>
> > 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.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
>
