List properties in JG not behaving as in Tinkergraph?

[thomas.dr...@gmail.com]

Hi,

I accidentally posted this question in the Janusgraph developer group. Now that I noticed this I'm reposting it here, as I think it fits better in here.

I'm currently learning gremlin/JG and was playing around with properties, as described here: https://kelvinlawrence.net/book/Gremlin-Graph-Guide.html#updatelist

In this book the author states that code like this:

g.addV("A").property("test", "test1").property("test", "test2")

would result in a Vertex A with property test containing two values, i.e., test1 and test2. 

When I do the same in JG, then only test2 is saved as the value of test.

Janusgraph only supports the above described behavior if I set "schema.default=tp3". 

However, when I do so, then JG again behaves differently elsewhere than the book describes, e.g., when updating the list property.

In the book they have two options of updating a list property, 

g.V(someId).property("test", "test3")

will replace the content of the list with test3, whereas

g.V(someId).property(Cardinality.list, "test", "test4)

will append the value test4 to the existing values. However, JG appends the value in both cases.

Is this an intended behavior? Or am I doing something wrong?

Any advice is highly appreciated :)

Kind regards,

Thomas

[Philip Graff]

Dear Thomas,

See the beginning of Section 4.7.5 in the Gremlin Graph Guide:

There is a subtlety to be aware of when using property. What happens can vary depending on the context in which it is used. Only when done as part of an addV step immediately followed by multiple property steps using the same key value will a list be created. Look at the two examples below. They do not produce the same results.

When you want to append a value to a list property outside of the context of addV(), you'll need to specify the list cardinality.

Cheers,

Phil 

[Thomas Driessen]

Hi Philip,

thanks for your answer. 

I tried what you suggested, but got a strange result. 

Let's take the following piece of (Java) code:

g.addV("A")
    .property("test", "test1")
    .property("test", "test2")
.iterate();
commit();

g.V().has("A", "test", "test2").property("test", "test2").iterate();
commit();

Map<String, Object> result = g.V().has("A", "test", "test2").propertyMap().next();

System.out.println(result);

For a JG graph with "schema.default = tp3" configuration this produces this result: {test=[vp[test->test1], vp[test->test2], vp[test->test2]]}

Whereas for a Tinkerpop graph the same code produces this result: {test=[vp[test->test2]]} (WhichI expected)

To me it looks like as if I have to predetermine the cardinality (single/list) of a property in JG (by using a DefaultSchemaMaker), whereas in Tinkergraph I can change the cardinality at runtime by using Cardinality.list/Cardinality.single.

I just wanted to check if this behavior of JG is intended or a technical limitation or a bug.

Kind regards,

Thomas

--
You received this message because you are subscribed to a topic in the Google Groups "JanusGraph users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/janusgraph-users/I6z6HF3GH-M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to janusgraph-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-users/c11cd6bf-26e1-47c5-9b35-868eed680683%40googlegroups.com.

[Thomas Driessen]

Just for people that come across the same problem:

I worked around this behavior of JG by reversing the approach one would take in Tinkergraph.

In Tinkergraph every property is assumed to be of Cardinality SINGLE if not stated otherwise by using Cardinality.list. 

In JG (if schema.default is set to tp3) every property is assumed to be of Cardinality LIST if not stated otherwise by using Cardinality.single. (i.e., vice versa of how it works in Tinkergraph)

In JG (if schema.default is not set at all) every property is assumed to be of Cardinality SINGLE and trying to change that by using Cardinality.list results in a SchemaViolationException.

Kind regards,

Thomas