How comfortable are we taking Jest on as a dependency? Or rather, if we take on Jest as a dependency, we'll need to be prepared to help push them along with fixes. Jest Issue 409 is for ES 5.0

(Sorry for the delay, I'm definitely used to lists where reply-to-list is the default, so I send this to @sjudeng along last Friday) Since I was the guy that spoke up on the Github issue regarding

Adam, thanks for chiming in on this thread. I asked to move the conversation to this dev mailing list for broader exposure to the community since there are only a few people following that specific

Regarding an initial release with full compatibility with Titan 1.0, what about creating an issue requesting a release be created based on an earlier commit before potentially breaking changes? In

Really, that would depend on the potential impact of the security flaw. Nothing within our infrastructure is directly accessible to outside access, and the API we present to customers is well

Hi, We have mostly completed work on a CQL storage backend for JanusGraph which is table compatible with the Astyanax implementation. There is still some missing functionality for some of the

Paul, that sounds great. The proposal to create a cassandra-core makes sense to me. What version of CQL are you coding against, 3.1 or 3.3?

Jason, currently we are targetting the 3.1.4 driver, but I don't think there is anything that precludes us from using the 3.3 version either, but I will check on that. We will look into completing the

I just pushed the commit to update to support ES REST client to the above PR. I figured the PR merge is on hold anyway pending the outcome here and I didn't want to sit on the 2.x/5.x work as I think

sjudeng, I think those commits might be the right way forward. It satisfies the need for http. Tested 1.x support, even with Jest, is difficult, and things get much easier with only supporting

Going forward do you think we'd next look at dropping transport client support and then updating to use Jest? If so I'd think you could just delete the `rest` package and replace with `jest`, which

I see your concern with the Lucene stuff. I think what I might be able to do is Get rid of the transport client. Move the starting of the server responsibility on to the test code and use the

Keith, I added a PR comment regarding testing before seeing this. Definitely would welcome your efforts on any of the items you mentioned. Probably need some consensus here regarding dropping

>clean up the implementation and still support conclusively testing against any (supported) ES distribution version. That's my main driver for this. I see having that transport client as pretty

Keith, Sounds good. Are you going to rebase those commits on mine or keep them separate for now? I want to avoid painful merge/conflict issues for either of us later down the line. Jason, Are we close

Hi all, We've got an initial implementation of the CQL based backend. At this stage it's been implemented as a completely separate module, however ideally we'd like to extract a cassandra-core module

sjudeng, I think the ES plan sounds good. This thread has been open for a while, and we have gotten any other input from the community. It sounds fair to start up a [VOTE] thread. Re: creating the

Let me know if this should be moved to another thread but is there any interest in scoping down the initial JanusGraph release to just be a "compatibility" release? There has been concern raised in

I'd like to request a vote on the following proposal for proceeding with updates to Elasticsearch in JanusGraph (see this discuss thread for more information): Update to support ES 2.x and 5.x with

I added a comment to the existing release discussion regarding creating an initial compatibility release and started a vote