int is returned as string

[zifnab87]

dev-master:today Hi, I am inserting an int and it is returned as a string. Here is my schema setup (it is integer obviously and saved): http://i.imgur.com/vc93Yq6.png

$data = ["IsOfTypeCount" => 10];
var_dump($data);
$transaction = $db->getTransactionStatement();
$transaction = $transaction->begin();
$record =  (new Record())
            ->setOData( $data )
            ->setOClass( "Entity" )
            ->setRid( new ID() );

$createCommand = $db->recordCreate($record);
$transaction->attach( $createCommand );
$transaction->commit();
$record = $db->query("select from Entity where @rid ='".$record->getRid()."'")[0];
$dataNew = $record->getOData();
 var_dump($dataNew);

//results:
array(1) {
  ["IsOfTypeCount"]=>
  int(10)
}
array(1) {
  ["IsOfTypeCount"]=>
  string(2) "10"
}

Thanks Michail

[Ostico]

Hi @zifnab87 , this is normal if you are using a 32bit version of PHP. On 32bit version of PHP or on a 32bit Operating system PhpOrient treat integers as string to avoid data loss because PHP can't handle 64bit integers without loss of significant digits.

https://github.com/Ostico/PhpOrient#warning-if-you-use-a-32bit-platform-you-must-use-one-of-these-libraries-into-your-application-to-avoid-the-loss-of-significant-digits-with-java-long-integers-furthermore-these-php-modules-should-be-loaded-to-achieve-better-driver-performances-on-these-systems

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

If you are not using a 32bit version of PHP surely it is a bug.

This is an easy test:

var_dump( PHP_INT_SIZE == 4 );
# in your system i'm expecting true

Let me know.

[zifnab87]

@Ostico Thanks for the quick and detailed reply! The code above returns true :) - My version is 64-bit but windows don't support 64-bit ints because php x64 builds are considered experimental :/ - But rethinking that I chose Integer in orientdb and according to https://github.com/orientechnologies/orientdb/wiki/Types I am not expecting anything bigger than 32-bit signed.So in that case isn't it safe to just have an integer returned (or there is a case of platform dependence for unsigned/signed int32)? I understand your point for long or anything 64-bit but right now I am planning to use only integers and not long numbers.

[Ostico]

Surely i can distinguish between 4Bytes Int and 8Bytes Long, because OrientDB send me this information, but for data consistency on 32bit platform i prefer to maintain everithing as string, alternatively every user should guess if the type of the data is "string/INT".

Moreover, if you use Java, or if you connect to a pre-existent database filled with data from other languages/clients that support 64bit int, you could have data loss or corrupt the database data.

[zifnab87]

Thanks again! Is there a way or will there be a way for me to know what orientdb type is each record property so I can safely cast it if I need to? Otherwise do you suggest using BCMath or GMP even with PHP x64 window build, will actually return those as ints or it won't since PHP_INT_SIZE will still be 4?

[Ostico]

With 64bit systems/build all types are correctly managed as INT 64bit. BCMath and GMP should be used on every php 32bit installation because they are much faster than php native implementation i made. They are Arbitrary Precision Mathematics, they treat int as strings so the 32bit systems can handle 64bit Long numbers.

At the high level ( user level ) there is not possibility at the moment to know wich type of field we are handling (float/long/int/short).

[zifnab87]

Thank you! I am closing the issue. I decided to try casting it and if there will be precision loss I send the propertyName_str and unset the other one (propertyName) back to the client.