Hi Graham, This was certainly one to investigate for the weekend. Where you started investigating from the inside of janusgraph, I started from the user perspective and this is what I did: I

Hi Timon, Adding to the answer of Ted, I can imagine that your new data enter your pipeline from a Kafka queue. With a microbatching solution, e.g. Apache Spark streaming, you could pre-shuffle your

Hi Timon, As I mentioned earlier, the only way I can think of (assuming you are not concerned about the consistency of data storage as Ted mentioned) is to modify JanusGraph source code: In

Hi Timon, Jumping in late on this one but I wanted to point out that even if you could read it prior to committing to check if your constraint is maintained, most of the JG storage layers do not

Thanks for your suggestion, but the consistency setting does not solve my problem.

Hi Simon, It seems that you can force JG to re-read elements just before commit according to https://docs.janusgraph.org/advanced-topics/eventual-consistency/#data-consistency I have never try the

Thanks for your reply. The issue is that we need to refresh some vertices mid transaction. Rolling back is not an option as that would erase edits that we're making in our transaction. Disabling

Hi @hadoopmarc, Thanks for replying and no apology needed - it's a good question. Although I failed to mention it in my question, I did set the credentials to ('graham','sass-password') in the

See if this helps: https://lists.lfaidata.foundation/g/janusgraph-users/message/5615 「<vamsi.lingala@...>」在 2021年3月4日 週四，下午4:42 寫道：

Hi Timon, I don’t even think you will be able to disable tx-cache by using createThreadedTx(), or equivalently, newTransaction()/buildTransaction(). Unfortunately, as long as your transaction is not

gremlin> g.V(6389762617560).valueMap() ==>{} gremlin> gremlin> g.V().hasLabel("MAID").has("madsfid","sfmsdlk").outE("MAIH1").as("e").inV().as("v").select("e", "v").by(valueMap()) ==>{e={},

Hi Marc, The backend used is Cassandra. I was just wondering if we can load the data from Cassandra's data store to the in-memory backend to speed up the process. I tried OLAP by configuring Hadoop

Sorry for asking, but you did not state it explicitly: you did modify your sasl-remote.yaml file to reflect the new ('graham', 'sasl-password') credentials, did you? Marc

Hi, I've been trying to use authentication over a websocket connection to a JanusGraph Server. If I configure the server to use a SimpleAuthenticator and a TinkerGraph for the credentials, as

Our application has transactions editing many vertices representing elements of a branch. This branch is also represented by a vertex that has boolean property isPublished. Before committing such a

The vertex centric index is written to the storage backend, so I guess the section on write performance configs should be

Thanks a lot for your reply Marc. I browsed through the older threads and didn't find a good solution for this. "BigTable cannot keep up with your index repair workers" - could you provide a little

I checked on the existing issues and the following one looks similar to your issue: https://github.com/JanusGraph/janusgraph/issues/1803 There are also some older questions in the janusgraph users

The stacktraces you sent are not from reindexing but from an index repair job. TemporaryBackendException is usually an indication of unbalanced distributed system components; apparently BigTable

Hi Marc, FYI: https://github.com/JanusGraph/janusgraph/discussions/2491 Greetings,Jan