Open voidzero83 opened 9 years ago
Hi @voidzero83 , you found the problem, but the solution is not good.
Php is not so intelligent with numbers. Position is a LONG ( so a float and not an integer as you cast ) and when php perform implicit casting operation from string to float some strange behaviours can happen.
Moreover casting Position to an integer or a float can lead to a loss of data in 32bit systems.
I'm working to better fix.
Thank you for reporting the issue.
Please, can you tell me if your PHP is compiled as 32bit or 64bit
Can you run this code in php console and paste the result?
var_dump( PHP_INT_SIZE );
This issue happens when you are using bags?
In the code nothing seems lead to this behaviour except the RidBag manipulation.
Moreover, if possible, can you provide me a code snippet to reproduce the issue?
Tnx
Hello,
I'm not able to reproduce now the issue in a snippet because I'm out for vacation and I'm still overloaded of some work to get completed. I can't give you access to the whole project for contractual reasons.
I use a 32bit apache on a 64 bit windows system on my local environment. On line I have a nginx based jelastic cloud that should be all 64bit. Actually I don't remember if the problem was only on my pc or online also.
I actually don't use the bags feature, the problem happened at the access of the current user (loaded by Rid). It happened almost randomly, apparently as a query cache or something similar. It never happened at the first page load, but often refreshing the same page (more times with the .000000000 than the right value)
My patch is actually ok for my needs (I use full 64bit system on production, locally 2billions of positions are more than enough), I'll follow the updates and if the problem is still there I'll fix it on my own.
var_dump( PHP_INT_SIZE );
locally: int(4) online: int(8)
Thank you.
2015-08-09 14:54 GMT+02:00 Domenico Lupinetti notifications@github.com:
Please, can you tell me if your operating system is 32bit or 64bit and if this issue happens when you are using bags?
In the code nothing seems lead to this behaviour except the RidBag manipulation.
Moreover, if possible, can you provide me a code snippet to reproduce the issue?
Tnx
— Reply to this email directly or view it on GitHub https://github.com/Ostico/PhpOrient/issues/31#issuecomment-129184188.
I also had an encounter with this same issue. Haven't figure out how to solve it
Can you tell me if your patch solved your issues in production?
Sometimes (apparently random) I receive this ID: PhpOrient\Protocols\Binary\Data\ID Object ( [cluster] => 12 [position] => 33.0000000000 ) instead of: PhpOrient\Protocols\Binary\Data\ID Object ( [cluster] => 12 [position] => 33 )
Actually I don't know why, I solved the problem by changing rows 48/89 in PhpOrient\Protocols\Binary\Data\ID to: $this->cluster = (int)$cluster; $this->position = (int)$position;
Apparently I've not problems anymore.