Thanks for your report. Can you please provide the following details: Which version of JanusGraph do you use? Are you sure you did not set the storage.drop-on-clear property to false? Do you have perm

Hi Tendai, I do not understand the concept of row contention. Is not this config row just the row that is retrieved most often on the region servers that contain it and are not other rows on these ser

Hi Albert, I tried with the GraphOfTheGods with janusgraph-0.5.3: So, I guess you did not mean to say that these traversals should fail. If it has anything to do with the way you use the PredicateCond

Hi Umesh, I assume that checking the compatibility matrix at https://docs.janusgraph.org/changelog/ made you post the additional comment about cassandra 4.0.0 :-) Indeed, support of cassandra 4.0 is s

Hi Marco, Interesting idea! From what I read about the EventStrategy, this is a feature stemming from TinkerPop and questions about it could best be addressed there. Note however that gremlin OLTP tra

Hi Anya, In v0.6.0 the bin/janusgraph-server.sh start script does not start Cassandra any more. Are you sure you did start Cassandra ("cassandra/bin/cassandra") before starting JanusGraph? Also check

Hi Mladen, Indeed, there is still a load of open issues regarding TTL: https://github.com/JanusGraph/janusgraph/issues?q=is%3Aissue+is%3Aopen+ttl Your last remark about empty vertices sounds plausible

Hi Mladen, Just two things that come up while reading your story: the cassandra TTL feature seems promising for your use case, see e.g. https://www.geeksforgeeks.org/time-to-live-ttl-for-a-column-in-c

Hi Pawan, Your code mirrors the example at https://docs.janusgraph.org/advanced-topics/eventual-consistency/#data-consistency for the greatest part. Are you sure the changes on graphMgmt get committed

Hi Matthias, Thanks for taking the trouble to report this. It took a while, but your report did not go unnoticed: https://github.com/JanusGraph/janusgraph/issues/2857 Best wishes, Marc

Hi, There is an issue tracking this, but no PR's yet, see: https://github.com/JanusGraph/janusgraph/issues/2325 Best wishes, Marc

Hi Krishna, Nope. However, you are not the first to ask, see: https://stackoverflow.com/questions/46363737/tinkerpop-gremlin-merge-vertices-and-edges/46435070#46435070 Best wishes, Marc

Hi Hazal, Your comment is correct: the graph.set-vertex-id feature is not documented further than this, so using it is not advised. You are also right that lookups in the index require additional proc

I read some conceptual confusion, so let me try: a single query is handled by a single janusgraph instance (In this case JanusGraph Server) you can handle many queries from many nodejs clients in para

Hi Pawan, 1. See https://docs.janusgraph.org/schema/#displaying-schema-information 2. See the manuals of your storage and indexing backends (and older questions on this list) 3. Please elaborate; some

Hi Toom, Yes, you are right, this behavior is not 100% consistent. Also, as noted, the documentation regarding text predicates on properties without index is incomplete. Use cases are sparse, though,

Hi, There are three solution directions: if you have keys to your vertices available, either vertex ids or unique values of some vertex property, you can start as many gremlin clients as your backends

Hi Toom, See, https://docs.janusgraph.org/index-backend/text-search/#full-text-search_1 Indeed, the negative text predicates are only available to Elasticsearch (and, apparently as you say, to the Com

Hi Claudio, Paging with range can only work with a vertex centric index, otherwise the vertex table is scanned for every page. If you just want all results, the alternative is to forget about the rang

Hi Tanroop, Does the problem also occur if you replace v() with V().limit(1) inside your query? If not, at what result size does your issue start to occur? Btw, your post has a typo: "user" and "uidx"