Closed homestar9 closed 5 months 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 ) )
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.
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:
5.1.3:
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.