Unmarshalling of an integer field seems to create a string

[andreyvk]

Hi @Ostico,

Im having problems with unmarshalling integer fields. I've seen this several times already happening on different record fields so I've decided to create this issue.

Here's what i have on DB side:

orientdb {db=test}>  select cancelNoticePeriod.type() from #84:2765                     
+----+------------------+
|#   |cancelNoticePeriod|
+----+------------------+
|0   |INTEGER           |
+----+------------------+

1 item(s) found. Query executed in 0.011 sec(s).

It says integer. However when I pull the same record with the library and then do a PHP print out like this:

echo gettype($rec["cancelNoticePeriod"]);

I get a string as a result. The real problem, of course, comes when I try to save the record back. Orient would throw me an exception:

com.orientechnologies.orient.core.exception.OSerializationException: Error on unmarshalling field 'cancelNoticePeriod' in record #84:2765 with value: cancelNoticePeriod:"60"
        DB name="test"

Thing is that it seems to happen occasionally, which is a disturbing... I will do more tests and update you as I go unless you have an idea why this is happening. Thanks in advance!

[Ostico]

Hi @andreyvk ,

sorry but this is by design: https://github.com/Ostico/PhpOrient#in-phporient-by-design-numbers-are-always-treated-as-strings-because-of-the-platform-dependant-nature-of-php-in-32bit-platform-numbers-must-be-treated-as-string-because-values-greater-than-232-would-be-lost-and-the-bcmathgmp-modules-must-be-used-to-avoid-this-to-make-the-results-consistent-for-all-platforms--32-and-64bit--and-leave-to-the-userdeveloper-the-decision-on-how-to-use-its-own-data--by-manual-cast--strings-are-used-for-all-numeric-data-types

[andreyvk]

I see. Thing is that it doesnt seem to happen always, although I need to test that thoroughly now. Btw, we're using a lot of double values and those dont seem to have any issues at all. Do you know why?

[andreyvk]

Hi @Ostico. Found the source of my issue: there was no schema defined for those particular attributes. Hence the problem. Thanks!

Was too quick to comment. I was looking at the wrong schema file. Still searching

[andreyvk]

Sorry

[Ostico]

Hi @andreyvk

there is the piece of code that consume numbers in the driver with CSV serialization: https://github.com/Ostico/PhpOrient/blob/master/src/PhpOrient/Protocols/Binary/Serialization/CSV.php#L259

as you can see in php running on 64bit int and floats are treated as numbers, in 32bit they are treated as strings.

[Ostico]

In serialization instead, if the driver find int and float, the driver use them as they are:

https://github.com/Ostico/PhpOrient/blob/master/src/PhpOrient/Protocols/Binary/Serialization/CSV.php#L523

[andreyvk]

That's interesting. Why does it happen only to integers then? I actually tend to think that orient itself should be (just like MySQL, for instance) accept numbers in string format too.

I might just write to the Orient guys and as that question.