Hi Joe, I have no detailed knowledge of the JanusGraph backend code myself, but just a reaction for clarification (so that others see more hints to the cause of the issue): Is it possible that the

gremlin> g.V().has("newid","xyz").valueMap(true).tryNext().isPresent() ==>false gremlin> g.V().has("newid",unfold().is("hash data")).valueMap(true).tryNext().isPresent() 07:01:35 WARN

g.V().has("newid", "xyz").count().profile() 04:31:35 WARN org.janusgraph.graphdb.transaction.StandardJanusGraphTx - Query requires iterating over all vertices [(newid xyz)]. Even though the newid

Hi all - I'm getting the following error when executing the following query: List<Object> correlationIDsListSource = traversal.V().has("source", source).outE("correlation").has("type",

> I've seen cases in the past, where queries relying on a mixed index fail while the index backend still hasn't caught up to the storage backend. Yes that could happen. You can use

That's a great post. This is exactly the use-case we have, with a type property. Regarding the usage of mixed indexes - - I'm less concerned with property updates in this case (as opposed to

Hi Assaf, I see. That makes sense and unfortunately, I don't have a perfect solution. I would suggest you use a mixed index instead. Regarding the data model, you can take a look at a blog I wrote

Hi Boxuan - thanks for the quick response! I get a feeling that 2) might be the issue. Since JanusGraph has never allowed us to index labels, we ended up having a "shadow property" which is set as a

Hi Assaf, Having too many vertices with the same label shouldn't be a problem. The two most possible causes are: 1) You have a super node that has too many edges. 2) You have a composite index with

Hi! We are using JG on top of Bigtable. While trying to understand some slow queries, I found the following in the Bigtable query vizualizer: "Large rows — Found 1 single key storing more than

Hello Marc, Actually my previous testing was incomplete. After removing those two log4j related jar files from the lib directory, I can start elasticsearch, cassandra and Janusgraph server

Apparently it replaces the full path to the properties file with a relative path (conf/remote-graph.properties), which isn't found, of course. So, I've copied them and now I can connect. Thanks.

The stacktrace is not very helpful, unfortunately, but that is not your doing. The original example does not use an "ats" variable but instantiates g with a oneliner, but it hard to see why this could

D'oh... So, after that, I get a NullPointerException: AnonymousTraversalSource<GraphTraversalSource> ats = traversal(); // not null if (new File(props).exists()) // path to

Hello Marc, Yes. Now it works! Thanks Yingjie

You can take a look at: https://docs.janusgraph.org/interactions/connecting/java/ Apparently, you used JanusGraphFactory, which opens an embedded JanusGraph instance in the client. If you want to

I should probably add I intend to use import static org.janusgraph.core.attribute.Text.* for textContains etc.

I'm trying to connect to janusgraph server from java. If I follow the instructions in the documentation, using this in gradle: implementation 'org.janusgraph:janusgraph-driver:0.6.2'

Hi Yingjie, My suggestion was incomplete. In addition to removing the log4j-1.2.17.jar file from the lib folder, you have to remove the slf4j-log4j12-1.7.30.jar file as well. Otherwise, JanusGraph

On Sat, Aug 20, 2022 at 09:28 AM, <hadoopmarc@...> wrote: The JanusGraph and TinkerPop code only explicitly depend on slfj4j, so you can choose the logging implementation. you want You can simply