Keith Lohnes <loh...@...>
I proposed Jest for a few reasons. The ES Rest client is rather low level, as mentioned in #92. Jest is much higher level client that adds a lot of niceties for Java. I think that alone will keep Jest around for a while.
WRT to versioning, unless there's another reason aside from Jest, 2.x and 5.x could be combined as they'll likely use the same Jest jar version.
Jest also makes it simple to use the same code across 1.x, 2.x, and 5.x versions for constructing ES queries. The code I've written doesn't use anything that would change/break between the two different versions of Jest that would need to be used for 1.x and 2+ compatibility, meaning we could easily introduce http for all 3 versions.
Either way, there's no additional effort to introduce http interface in 2.x vs 5.x alone.
As I mentioned in #79 there are a couple of prs that would need to be merged in Jest for 5.x to work completely correctly.
On Friday, March 3, 2017 at 10:26:49 AM UTC-5, Jason Plurad wrote: It's also similar to the split that we'll have with Cassandra with cassandra-thrift and cassandra-cql.
Since ES is going in the direction of HTTP-only client access ( good read here), it might make more sense to use their client API rather than Jest. With ES introducing their own Java REST Client with version 5.0.0, I wonder what Jest's longevity would be, other than perhaps backwards compatibility with pre-5.0 ES versions. On Friday, March 3, 2017 at 10:08:57 AM UTC-5, Alexander Patrikalakis wrote: In the scheme below if 1.5=transport and 2.x=transport and 5.x=http/jest, then we don't need to pull out protocols in the shim names, so the shims would just be: janusgraph-es/janusgraph-es1 janusgraph-es/janusgraph-es2 janusgraph-es/janusgraph-es5 On Saturday, March 4, 2017 at 12:07:24 AM UTC+9, Alexander Patrikalakis wrote: resending because I made a typo: hadoop -> hbase
We could do a split for ES much like the split that we do for hbase (098, 10 etc). have a janusgraph-es/janusgraph-es- core that JanusGraph uses, and shims like janusgraph-es1, janusgraph-es2-transport, and janusgraph-es5-jest. Since we are newly introducing 2.X support in the in-flight PR and the coding is already done, perhaps we only add transport support on es2 lineage and only support HTTP/jest on es5 lineage? On Friday, March 3, 2017 at 12:40:07 AM UTC+9, Keith Lohnes wrote: I started some conversation over at https://github.com/JanusGraph/janusgraph/pull/79#pullrequestreview-24343839, and Jason Plurad suggested I move that over here.
I have some code that's been used in a Titan deployment using the apache licensed Jest ES http client. There was some discussion in that PR about whether to continue to support the Transport/node client in there as well.
The key points of the conversation there 1. Versions to support (1.x, 2.x, 5.x)
With the Jest client, we could support all three pretty easily. 1 vs 2.x and 5.x would be changing the .jar out. There's some open PRs in the Jest repo that need to get merged for 5.x support, but once those are and we update the jar version, we'd be able to support 5.x. Maintaining 1.x support for a little while would be nice for people with production Titan instances, as Adam Phelps pointed out. 1.x and 2.x could use the same code, they just need different jars.
2. HTTP vs Transport/Node I think in #92 there's a mention of Transport being deprecated. My first instinct is to say that Janus should mark Transport/Node as deprecated and continue to support Transport/Node clients until a major version release at which point support could be removed. I have some work done to split out the Transport/Node clients from the Http client, and make for an easy removal once that decision has been made.
|
