Josh Shinavier has been doing the most thinking around some form of Schema API for TinkerPop, but I couldn't say what the timeline is at this point for such work to make it into TinkerPop. I know he's

IMHO the implementation of a Gremlin way to manage schemas does not provide a major benefit unless it's somewhat standardized in Tinkerpop. An HTTP API would have the benefit of

Hi everyone, I started nearly one year ago to investigate how we can revamp JanusGraph Management. Why do we want to revamp JanusGraph Management? Schema Management and Index Management is buggy and

Hi, I am sharing my experience of Janusgraph Bulk Loading: Data Store: Cassandra Index Store: Elasticsearch Audit Data: Kafka Topic Data loaded: ~300M Nodes & ~371M Edges. Spark Cluster: 33

On behalf of the JanusGraph Technical Steering Committee (TSC), I'm pleased to welcome a new Technical Steering Committee member on the project! Jan Jansen has provided major contributions and has

+1 I think it makes sense for us at this stage of JanusGraph to keep the burden of maintaining old versions as low as possible so we can focus on improvements (be it refactoring, supporting new

Hi Serge, I'm not in front of computer right now, so can't verify why you are getting the error in first portion. It still seems to be reading ES config from somewhere. I suspect the

Thanks Debasish, I haven't modified any configuration file. I'm just running the docker image as is from the image repository as I indicated. I tried the following as you suggested. Not sure if I'm

Absolutely agree that "Graph of the Gods examples would be the first thing a new user would try yet it doesn't work out of the box”. I wonder why JanusGraph doesn't have a

Are you specifying the elastic search index connection properties in your berkey.properties file? If you don't want to use ES and using this just for exploration purpose then you can use

Old post but still relevant two years later. I expect try the Graph of the Gods examples would be the first thing a new user would try yet it doesn't work out of the box. Even when using the I tried

Hello. Awesome job! I have a couple of questions about your data loading approach if you don't mind. Is it simply aggregating writes locally before writing them to Snowflake?

Hi Russel, Just posted an update on the other Thread, and well as you might have guessed already, its finally all about extending the right set of interfaces for enabling JanusGraph with your target

To anyone if they are following this Thread. Wanted to post an update if anyone is interested, else will close out the Thread. So, We were able to get the adopter working for SnowFlake. We planned on

I am proposing to drop support for "0.4" branch in favor of "0.5" branch as discussed here: https://groups.google.com/d/msg/janusgraph-dev/LhZBlw0_N3o/emCrF2Y-AQAJ The reasons are the next: - "0.4"

This vote is now closed with a total of 4 +1s, no +0s and no -1s. The results are: BINDING VOTES: +1 (3 -- Oleksandr Porunov, Florian Hockmann, Jason Plurad) 0 (0) -1 (0) NON-BINDING VOTES: +1 (1

* Imported KEYS file and verified GPG signatures on pre-built distribution files * Downloaded source code archive and built a distribution * Verified the release tag matches the zipped source code *

This vote is now closed with a total of 3 +1s, no +0s and no -1s. The results are: BINDING VOTES: +1 (3 -- Oleksandr Porunov, Florian Hockmann, Jason Plurad) 0 (0) -1 (0) NON-BINDING VOTES: +1

* Imported KEYS file and verified GPG signatures on pre-built distribution files * Downloaded source code archive and built a distribution * Verified the release tag matches the zipped source code *

I would like to get following PR https://github.com/JanusGraph/janusgraph/pull/1940 merged before releasing 0.5.0. This would prevent to breaking changes of janusgraph-hadoop in two releases.