Hi, Is there any plans that Janusgraph to be certified on Hbase 2.0 version as we are currently using Janusgreaph0.2.0 with Hbase 1.1.2, but planning to upgrade our Hadoop version to 3.x. For this we

Yes, +1 for the separate repo. Am Dienstag, 21. August 2018 03:04:23 UTC+2 schrieb Ted Wilmes:

Hey Chris, Appreciate the extra stir and yes, I'm in agreement. +1 for a separate repo. Thanks, Ted

Stirring one more time. Ted and Florian are you guys in favor of the creation of a repo for an official JanusGraph docker image?

Hello I face following scenario : several threads trying to increment a property value on same edge. Actual behavior : last commit is the value that stays after threads are done The question is :

And next time please use JanusGraph users mailing list for such queries :-)

Hi Manish, Well you are adding List property to JanusGraph in wrong way. The way I do to create List properties once the schema is defined is as follows: The following things should work, and if it

I have this code: JanusGraph graph = JanusGraphFactory.open("/janusgraph-0.2.0-hadoop2/conf/janusgraph-cassandra.properties"); JanusGraphManagement mgmt =

Thanks Misha! I just created the initial PR: https://github.com/JanusGraph/janusgraph-dotnet/pull/1 Am 16.08.2018 um 17:56 schrieb Misha Brukman:

Well, in that case, well we will just add corresponding columns to the matrix corresponding to versions of the GLVs we are producing. Well, as I said before, both the idea seems good to me, but since

Hi Florian, Please feel free to open PRs on https://github.com/JanusGraph/janusgraph-dotnet and update the authors/contributors accordingly in addition to other files (readme). I've also activated

I'll populate the new JanusGraph repos with boilerplate license + DCO + Authors/contributors files, and then please feel free to follow the PR approach to bring in the code (and update copyright,

There was a recent thread where a developer was exploring using Solr as the storage backend for JanusGraph. I'd suggest looking over the code for the in-memory or BerkeleyJE storage backends to get an

+1 to the proposal (and +1 on the name).

Yes, we can publish driver docs easily under docs.janusgraph.org/dotnet/x.y.z/index.html I still think version numbers should be independent between projects. We already have a dizzying array of

+1 for janusgraph-ambari

+1 for a single janusgraph-docker repo. Wouldn't you be able to use the directory structure to manage the different flavors of a Docker image that we want to publish to Docker Hub? I wouldn't want to

Doh, yet another GitHub setting update was required. Should be correct now.

The problem I see with 4 digit versions where the first 3 are given by the JanusGraph version is that we couldn't express whether a release is a patch release or whether it contains new features (or

I would prefer any version, but I was thinking maybe aligning with JanusGraph version shall make it better, as user won't have to have a headache to which version to download, and it also gives us