valid property names in graph API

[Nicolas Delsaux]

Hi
I'm currently trying to make sure my graph mapping library
(https://github.com/Riduidel/gaedo) supports OrientDB.
I must confess first tests are not that satisfying : it seems there are
invalid characters for property names, contrary to what Blueprints doc
states there
http://www.tinkerpop.com/docs/javadocs/blueprints/2.5.0/com/tinkerpop/blueprints/Element.html#setProperty(java.lang.String,%20java.lang.Object)

> key - the string key of the property

Indeed, when I try to call the setproperty method with

key = "java.util.Map$Entry___key"
value = "java.lang.String___a"

nothing happens. AT ALL.
is there a reason for this lack of reaction of orientDB ?

Is there a way to configure the way orientDB reacts when encountering an
unsupported character in property key or value ?

Could it be possible to add this limitation to Blueprints implementation
to the
https://github.com/orientechnologies/orientdb/wiki/Graph-Database-Tinkerpop
page ?


I must - to my big disappointment - confess this code is tested and
works exactly as expected with two other Graph implementations :
TinkerGraph (quite logical) and neo4j.

Do I have to plan a long adaptation delay to have my API working with
OrientDB ?

Thanks

--
Nicolas Delsaux

[Luca Garulli]

On 14 August 2014 11:33, Nicolas Delsaux <nicolas...@gmx.fr> wrote:

Hi
I'm currently trying to make sure my graph mapping library (https://github.com/Riduidel/gaedo) supports OrientDB.
I must confess first tests are not that satisfying : it seems there are invalid characters for property names, contrary to what Blueprints doc states there http://www.tinkerpop.com/docs/javadocs/blueprints/2.5.0/com/tinkerpop/blueprints/Element.html#setProperty(java.lang.String,%20java.lang.Object)

> key - the string key of the property

Indeed, when I try to call the setproperty method with

key = "java.util.Map$Entry___key"
value = "java.lang.String___a"

nothing happens. AT ALL.
is there a reason for this lack of reaction of orientDB ?

Is there a way to configure the way orientDB reacts when encountering an unsupported character in property key or value ?

Could it be possible to add this limitation to Blueprints implementation to the https://github.com/orientechnologies/orientdb/wiki/Graph-Database-Tinkerpop page ?

You can configure OrientDB to be less strict than Blueprints that doesn't accept NULL values and the "id" property name:

graph.setStandardElementConstraints(false);

But in your case the problem seems to be the dot (.). In OrientDB with the dot-notation you cross embedded objects (this isn't supported by Blueprints and Neo4J).

Can you try to set this against vertex/edge before to set the property?

v.getRecord().setAllowChainedAccess(false);

If this works (please let me know it), we can fix BP implementation to implicitly call this method against all the vertex/edge underlying documents.

 

I must - to my big disappointment - confess this code is tested and works exactly as expected with two other Graph implementations : TinkerGraph (quite logical) and neo4j.

Do I have to plan a long adaptation delay to have my API working with OrientDB ?

Strange property names apart, which are the other problems (I already saw other email about transactions & indexes) ?

Lvc@

 

Thanks

--
Nicolas Delsaux

--

--- You received this message because you are subscribed to the Google Groups "OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to orient-database+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nicolas Delsaux]

On 14/08/2014 18:53, Luca Garulli wrote:
>
> You can configure OrientDB to be less strict than Blueprints that
> doesn't accept NULL values and the "id" property name:
>
> graph.setStandardElementConstraints(false);

In fact, for historical reasons, gaedo never stores null values (and
initial versions even failed when any null value was encountered). So
it's not really a problem for me.

>
> But in your case the problem seems to be the dot (.). In OrientDB with
> the dot-notation you cross embedded objects (this isn't supported by
> Blueprints and Neo4J).
>
> Can you try to set this against vertex/edge before to set the property?
>
> v.getRecord().setAllowChainedAccess(false);
>
> If this works (please let me know it), we can fix BP implementation to
> implicitly call this method against all the vertex/edge underlying
> documents.

I've tried it, and it seems to raise back old bugs ...
I will do more investigations soon.

>
> Strange property names apart, which are the other problems (I already
> saw other email about transactions & indexes) ?
>

The strange property names bug has extended since my first mail : I've
hunted down all locations where "." and ":" characters were used, and
replaced all with instance of constants that are configured from system
properties, just to discover that, as property names are URLEncoded as
UTF-8, using any non pure ASCII character drives to immediate failure,
due to

java.lang.IllegalArgumentException: Invalid field name
'out_com_dooapp_gaedo_test_beans_Post-%3Eauthor'. Character '%' is invalid
at
com.orientechnologies.orient.core.record.impl.ODocument.checkFieldName(ODocument.java:1668)
at
com.orientechnologies.orient.core.record.impl.ODocument.field(ODocument.java:761)
at
com.orientechnologies.orient.core.record.impl.ODocument.field(ODocument.java:673)
at
com.tinkerpop.blueprints.impls.orient.OrientVertex.createLink(OrientVertex.java:150)
at
com.tinkerpop.blueprints.impls.orient.OrientVertex.addEdge(OrientVertex.java:708)
at
com.tinkerpop.blueprints.impls.orient.OrientBaseGraph.addEdge(OrientBaseGraph.java:527)
at
com.tinkerpop.blueprints.impls.orient.OrientBaseGraph.addEdge(OrientBaseGraph.java:57)
at
com.dooapp.gaedo.blueprints.indexable.IndexableGraphBackedFinderService.createEdgeFor(IndexableGraphBackedFinderService.java:216)
at

I find particularly strange that URLEncoded values can't contain "%", as
this character specifically allows the use of any non-ASCII character.

But, well, appart property names characters, and transactions and
indexes compatibility, I hope that's all the interpretation differences
I will find ...


--
Nicolas Delsaux