Loading embedded set of documents in OrientDB 3.0.17 TP3

[rafasantodomingo]

OrientDB Version: TP3 OrientDB 3.0.17

Java Version: 1.8.0_111

OS: Windows 7 Enterprise

Expected behavior

Load a property defined as an embedded set of ODocument into a vertex of a class that contains such property in the schema

Actual behavior

Unexpected validation exception on committing to database when the property is added before the vertex has been assigned to the class. It is done correctly when the property is added after the vertex has been assigned to the class

Steps to reproduce

• Test 1: Embedded set of ODocuments after class property Vertex v = graph.addVertex(); // create empty vertex v.property(mandatoryField, value); // add mandatory fields … v.property(“@class”, orientClass); // assigned to class v.property(embeddedSetField, oDocumentSet); // add embedded set of Documents graph.commit(); // commit to database

• Test 2: Embedded set of ODocuments before class property Vertex v = graph.addVertex(); // create empty vertex v.property(mandatoryField, value); // add mandatory fields … v.property(embeddedSetField, oDocumentSet); // add embedded set of Documents v.property(“@class”, orientClass); // assigned to class graph.commit(); // commit to database

Test 2 throws a validation exception on committing to the database becasue for some reason only the first value in "oDocumentSet" is taken, so the value is treated as a ODocument instead of a ODocumentSet and hence the validation exception!

[luigidellaquila]

Hi @rafasantodomingo

Setting @class as a property is definitely not a good practice and is not the intended way to use the API, I'd strongly suggest you to use the following instead:

Vertex v = graph.addVertex("class:orientClass");

Thanks

Luigi

[rafasantodomingo]

Many thanks Luigi,

The thing is that doesn't seem to work in OrientDB Tinkerpops 3. In fact, we have found two problems:

• OStorageException: When we do a graph.addVertex("class:MyClass") it throws an OStorageException with the message Error on executing command: create class class:MyClass extends V. Following the error log it seems that it is caused by a _java.nio.file.InvalidPathException: Illegal char <:> at index 5: class:myclass265902927.cpm

• OValidationException: Even if we could use the graph.addVertex("class:MyClass") method, after OrientDB 2.2.12 it seems that the validation exceptions are thrown in the vertex declaration instead of on committing to the database. This means that when we assign the vertex to a class we need to add all the mandatory properties of the class in the same line. Otherwise it will throw an exception. In OrientDB 2.2.12 that didn't happen, which was good because most of the times our code does not know all the mandatory property values when a vertex is created.

[luigidellaquila]

Hi @rafasantodomingo

Sorry, my bad, please remove the "class:" from the addVertex():

Vertex v = graph.addVertex("theOrientClass");

The problem with the validation is a known one: OrientDB does data validation at each record save, and TinkerPop implementation performs a save at each operation, also after the addVertex(). If you already know the values for the mandatory properties, you can create the vertex and set them in a single operation:

graph.addVertex(T.label, "theOrientClass", "name", "Foo");

I hope it helps

Thanks

Luigi

[rafasantodomingo]

Thanks again Luigi,

"The problem with the validation is a known one: OrientDB does data validation at each record save, and TinkerPop implementation performs a save at each operation, also after the addVertex()."

Ok, is the idea to change this in the future? As said, in OrientDB 2.2.12 Tinkerpops implementation it didn't happen.

[luigidellaquila]

Hi @rafasantodomingo

Hard to say, it's not in the roadmap now, but we can discuss it

Thanks

Luigi

[rafasantodomingo]

It'd be great if you could have a look at it, because most of the time we don't know all the mandatory values when we create a record. We can of course store the data in memory until we've got all the mandatory values, but it's not the best option in terms of performance - and we'd need to restructure our code, which works fine with ODB 2.2.12

Many thanks, Rafa

[luigidellaquila]

Hi @rafasantodomingo

I'll check it and let you know

Thanks

Luigi