coldbox-modules / quick

A ColdBox ORM Engine
https://quick.ortusbooks.com
MIT License
23 stars 19 forks source link

[5.1.3] Primary Key Returning Decimal Instead of Integer #200

Closed homestar9 closed 5 months ago

homestar9 commented 2 years ago

Upgrading from 5.1.2 to 5.1.3 introduces a bug where the primary key returns a decimal instead of an integer when getting the memento of an entity that was just created.

5.1.2: image

5.1.3: image

Engine Tested: ACF 2018.0.14 and ACF 2018.0.15 DB Engine: MSSQL Server

Interestingly, in 5.1.2, the memento returns a string instead of a number, as noted by the value wrapped in double quotes. Perhaps the intent of 5.1.3 was to ensure the value gets returned in numeric form. However, ACF is including the decimal for some reason which will throw off any app that expects the primary key to be an integer.

I will report back when I have more information but wanted to let @elpete know since this feels like a big one IMO.

homestar9 commented 2 years ago

Confirmed. The issue is with ACF only (thanks Adobe) and has to do with how ACF handles val() which was introduced in https://github.com/coldbox-modules/quick/commit/1092a8e5c633ba4ee9c1e4b69fa5f487b2070b78

Here's a Gist that shows the problem: https://trycf.com/gist/1b7e7b0f1487443b0b59f985bedcf5d0/acf2018?theme=monokai

If you switch to Lucee, val() returns an integer. On ACF, for some reason, val() returns a decimal. Wrapping val() with int() should fix the issue like this: int( val( generatedKey ) )

homestar9 commented 2 years ago

@elpete https://github.com/coldbox-modules/quick/pull/201

homestar9 commented 2 years ago

I just thought of something that might be important for ACF users... what happens if the database is using a bigint instead of a regular int? Using val() on a massive integer will return notation like this: 9.999999933720369E23. Wrapping it in int() will return the largest possible integer in ACF, which is 9223372036854775807.

ACF Example:

writeOutput( int( 999999993372036854775808 ) ); // returns 9223372036854775807 

The only thing I can think of right now would be to use Java's java.math.BigInteger instead for bigInt situations.

Looping in @wpdebruin to see if he has any suggestions.