Again, my comment is explicitly NOT about the predicates. Those are indeed easy to add and implementors can differ in what they choose to provide and how they implement those.
I am only talking about providing a data type definition so that the server and client can agree on how such data moves between the two. That's where things are currently getting crazy. On Tue, Jan 26, 2016 at 11:51 AM Marko Rodriguez <[email protected]> wrote: > Hi, > > I think Pieter echoes my sentiment about supporting Geo and Time in > TinkerPop. A similar predicate people wanted in the past was RegEx. The > problem, ElasticSearch RegEx is different from SQL is different from ??… > I'm not hip to the Geo- and Time-scene, but I suspect that Geo is a crazy > rat's nest of standards, competing Java APIs, and the like. I don''t think > TinkerPop should choose. Its really easy for graph system providers to > provide P-predicates for predicates they wish to support (and what is > specific to their database). > > > https://github.com/apache/incubator-tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/P.java > > https://github.com/apache/incubator-tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/P.java#L122-L182 > > import static > com.a.super.rich.company.that.hoards.cash.money.GeoP.* > … > g.V().has("location", > inside(circle(12.234,34.235))).out("worksFor").values("name") > g.V().has("location", > outside(rectangle(12.234,34.235,23,11.57))).out("collaboratesWith").values("name") > > > …again, I'm not the most knowledgeable here, but when I read Pieter's > response, I was like -- "yea." > > Marko. > > http://markorodriguez.com > > On Jan 26, 2016, at 11:03 AM, pieter-gmail <[email protected]> > wrote: > > > Hi, > > > > Regarding Geo I have no strong opinions. However I thought I'll indicate > > what I have implemented in Sqlg. > > > > Postgres via Postgis has rather sophisticated gis support. In fact it is > > so sophisticated that I realized without spending considerable time > > learning it I don't really know what all is involved. I did however add > > partial support for the types that the postgis jdbc driver supports. > > Point, Polygon, GeographyPoint and GeographyPolygon. Geometry being on a > > flat earth and geography for a spherical earth. The driver has more > > constructs that I do not yet support. > > > > Further I did not consider adding any gremlin gis support as the gis > > concepts quickly become so complex that I deemed it better to leave this > > at the native sql level. Not sure what gremlin's gis ambitions are but > > chances are that a single lowest common denominator Point field will not > > suffice. > > > > Cheers > > Pieter > > > > > > On 26/01/2016 03:26, Matthias Broecheler wrote: > >> Hello everybody, > >> > >> one of the great features of TinkerPop is that it is extensible. It is > >> pretty easy for an implementation of TinkerPop Gremlin to add support > for a > >> regular expression predicate, for instance. > >> > >> In addition, it is also possible to add custom data types based on the > >> pluggable serialization system. However, unlike a custom predicate, > support > >> for custom data types requires changes both on the server side (i.e. > within > >> a particular implementation) as well as on the client side so that > clients > >> can read and make sense of such types when they are returned. > >> > >> This makes it fairly impractical for implementations to support custom > data > >> types. While it is easy to make the necessary changes on the server > side, a > >> particular implementation would have to extend each and every driver of > the > >> TinkerPop ecosystem in order to have its data type supported across the > >> board. The last part is what makes it impractical. > >> On top of that, since TinkerPop doesn't prescribe what the data type > must > >> look like, implementations can differ in their approach making it > >> impossible for drivers to support them even if they invested the > additional > >> effort. > >> > >> Hence, I would like to make the case for including a "Geo" and a "Time" > >> data type. Both are very common in the database world, very well > understood > >> (i.e. in how they should be represented and what they mean) and likely > to > >> be supported by a non-trivial number of implementations. > >> If TinkerPop defines what these datatypes should look like, all drivers > can > >> support them. > >> > >> Note, that I am only advocating to declare the data types - not the > >> predicates or operations on the types. The latter part could be > >> controversial and should be left to implementations of TinkerPop. > TinkerPop > >> should only dictate the structure of the datatype and how it is > serialized > >> (both for gryo as well as graphson) to make communication possible. > >> > >> For time, I suggest we follow the lead of Java's Instant which seems > well > >> thought out: > >> https://docs.oracle.com/javase/8/docs/api/java/time/Instant.html > >> For geo, I suggest we initially focus on 2D spherical coordinate > (latitude, > >> longitude) and the simple geometries of WKT which is widely supported in > >> the database world: > >> https://en.wikipedia.org/wiki/Well-known_text > >> > >> WDYT? > >> Cheers, > >> Matthias > >> > > > >
