[orientdb] Double values equal to or greater than 10mln are stored as String

[Salvatore Piccione]

Hello,

I've discovered an odd behaviour of OrientDB GraphEd 1.0rc9: double values equal to or greater than 10mln (10000000.0) are stored as String so when I load them from the graph and try to use as doubles I get a ClassCastException. A very simple test case that reproduce the error is available at https://gist.github.com/2252681. It creates a Vertex with two properties: one stores a double primitive and a second one stores a double object. The failing assertions are in:

• line 71 - it throws a ClassCastException because the double primitive value is stored as String rather than a double;
• line 72 - it compare two double objects and throws a java.lang.AssertionError with this message: expected:<1.0E7> but was:<1.0E7d>

The problem raises with both local and remote graph databases. I'm using OrientDB on 64bit OSs (client = Windows 7, server = Windows Server 2008 R2).

Could this be a bug or something that can be fixed by tuning some config parameters on Orient?

TIA,

Salvatore

[Luca Garulli]

Hi,

this is a bug! Have you tried if the problem persists in case you declare that property as DOUBLE in the schema?

Lvc@

[Salvatore Piccione]

Hello,

I've refactored the test case at https://gist.github.com/2252681. Now it has two test methods

• testUsingDefaultVertexClass - here both double properties are stored using the default OGraphVertex class
• testDeclaringFieldInClass - here both double properties are declared as OType.Double fields.
  

Here are some updates:

• If you run them on a 32bit JVM and you connect to the server in local mode, both test methods are executed successfully.
• If you run them on 32bit JVM and you connect to the server in remote mode, testUsingDefaultVertexClass fails in the same manner described in my previous e-mail BUT testDeclaringFieldInClass succeed.
  

Monday I'll let you know the result of running that test case on a 64bit JVM.

Thanks and regards,

Salvatore

2012/3/30 Luca Garulli <l.ga...@gmail.com>

[Salvatore Piccione]

Hello,

the result of the test case at https://gist.github.com/2252681 run on a 64bit JVM are the same as the one obtained running it on a 32bit JVM. This is a blocking issue for us because we work in schema-free mode so we use the same Vertex property to store any kind of data (i.e. not only double numbers but also integer numbers and strings) so we can't use the trick of defining a double property in the OClass of OGraphVertex.

Should I open an issue for this... and keep finger crossed to fix this issue ASAP ;) ?

TIA,

Salvatore

2012/3/31 Salvatore Piccione <salvo...@gmail.com>

[Luca Garulli]

Hi Salvatore,

I'm debugging it right now. it should be straightforward to fix thank you to your Test Case: OrientDB folks, please follow the Salvatore's way providing a test case to have a fix in short time ;-)

Lvc@

[Luca Garulli]

However, in the meanwhile, to get it working you could force an application conversion using the raw OrientDB api:

double d = doubleV.getRawElement().field("double", OType.DOUBLE)

Lvc@

[Luca Garulli]

Fixed as SVN r5116.

Scientific notation waited for a - after the "E". Example: 1.23456789E-9 but Java toString() produces: 1.23456789E9.

Now both the syntaxes are supported.

Lvc@

[Salvatore Piccione]

Thanks Luca!!! I'll give it a try in the next days!

2012/4/2 Luca Garulli <l.ga...@gmail.com>