Hi, for below sample code. storage backend is Hbase, "name" is used as index, it will at least has two rows update: but what if index update succeed while vertex update failed(throw exception).

Hi everyone, I downloaded a fresh spark binary relaese (spark-2.4.0-hadoop2.7) and set the master to spark://127.0.0.1:7077. I then started all services via $SPARK_HOME/sbin/start-all.sh. I checked

On behalf of the JanusGraph Technical Steering Committee (TSC), I'm pleased to welcome a new committer on the project! Dmitry Kovalev made a major contribution with the production-ready in-memory

I now experimented with many types of settings now for the cql connection and timed how long it took. My observation is the following: -Embedded with bulk loading took 16 min - CQL without bulk

index.search.backend=elasticsearch index.search.hostname=127.0.0.1 index.search.elasticsearch.client-only=true Do you think it is due to elastic search?

For "violation of unique key" it could be the case that cql checks id's to be unique (JanusGraph could run out of id's in the batch loading mode) but i'm not sure what the embedded backend is

Your block-size should be large in this example, see Id Creation: https://www.experoinc.com/post/janusgraph-nuts-and-bolts-part-1-write-performance Am Dienstag, 8. Oktober 2019 09:05:56 UTC+2 schrieb

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