Hello everyone! Though I generally just lurk and absorb everyone's collective wisdom, today I wanted to let you know we'll have a pair of JanusGraph practitioners speaking at Scylla Summit this year,

Hi Jan, So I tried it again. First of all, I remembered, that for cql I need to commit after each step. Otherwise, I get "violation of unique key" errors, even though I am actually not. Is this

Hi Jan, Ok then I probably screwed up somewhere. I kind of thought this was to be expected, which is why I did not check it more thoroughly. Maybe the way I persisted is not working well for cql. I

hi, I think that embedded cassandra can lead to some classpath hell, so this option should at least not be possible with default installation. I have a project where I put my library into janusgraph

We don't see this problem on persistence. It would be good know what takes longer. Do like to give some more informations? Jan

Hi Lilly, Thanks for explaining, I feared already that I had missed something. I think each type of query has its optimal treatment. When you have two properties to select on, you would have the

Thanks Abhay and Marc. It came as a bit surprise due to existing behavior in Titan. This is a bit restrictive given the nature of my app where other than few fixed properties which are defined by the

Hi Marc, I guess I did not explain my issue very well. What I meant to say is this. Suppose these ids correspond to some filtering criterion. Now having these ids I can create the subgraph. However,

Hi Lily, When you have the vertex id, you do not need any index. The index is a lookup table from property value to vertex id. Cheers, Marc Op maandag 7 oktober 2019 08:15:50 UTC+2 schreef Lilly:

Java 11 is simply not supported right now. So you have to use Java 8: From the Getting Started section of the docs Am Dienstag, 1. Oktober 2019 16:34:59 UTC+2 schrieb nix...@...:

Please share a code listing that shows how you have created the indices and your Gremlin traversal that results in this warning. Am Mittwoch, 2. Oktober 2019 13:06:02 UTC+2 schrieb arnab kumar pan:

JanusGraph doesn't provide any utility for this on its own. You can instead simply refer to your backend, ScyllaDB in your case, and make a backup of that just like it would be done without

Hi Jan, I found very noticeable performance improvements on graph persistence. It took considerably longer to persist a large graph via cql. Is this unusual ? Lilly Am Montag, 7. Oktober 2019 10:28:18

Hi Lilly, Where do you see massive performance improvements? Greetings, Jan Am Montag, 7. Oktober 2019 08:18:32 UTC+2 schrieb Lilly:

I forgot to add a link to the discussion: https://groups.google.com/forum/#!topic/janusgraph-dev/zU22a9wHS9A

Hi, I use it, since it turned out to perform much faster than the CQL backend. Especially for persisting a large graph. I thought this was in fact the justification for its existence? Hope it will not

Hi Marc, Thanks for your reply! Your suggestions would fetch the subgraph efficiently. However, on this subgraph I could no longer use any of my other indecees. Say I have an index on "property".

Hi We want to know if anybody uses the cassandraembedded backend in Production? Why do you use this backend? Can you use the CQL backend instead? In process of removing the Thrift backend, we want

Hi Bharat, Janusgraph being more consistent it stores only one PropertyKey with a defined any defined name with only one data type throughout the graph. Like in your case "Status" can't be of 2 data

Hi Lilly, Interesting question. For the JanusGraph backends to lookup the vertices of the subgraph efficiently, they need the id's of the vertices. The traversal is then g.V(ids) . There are different