I’m wrestling with a pattern match failure that I can not explain. It happens only on OTP 19 (not OTP 18) and only on the Ubuntu VMs as configured on travis-ci.org. (I can not reproduce on my Mac, which is also using OTP 19.)
The relevant code in question is in https://github.com/scouten/sqlite_ecto. (I’m trying to update sqlite_ecto so that it runs in OTP 19. This is a step along the way to seeing if I can make it work with Ecto 2.x.)
I’ve tried to narrow it down to a simpler case, but that case works as expected.
https://travis-ci.org/scouten/sqlite_ecto/builds/186266623 contains an example of this failure pattern.
Look for the string “HEY, WATCH THIS” in the debug build (look for the extended logs, and then scan down about a page). In the OTP 18 builds, you’ll see the following pattern:
translate_value value = 1 is_integer = true type = "decimal(2,1)"
yup, matches
tv integer clause result = 1.0 is_integer = false
tv float clause float = 1.0 precision = 2 scale = 1
result = #Decimal<1.0>
which means that the pattern match at https://github.com/scouten/sqlitex/blob/0367a06b9308093e1d7fe564278650031c44f18b/lib/sqlitex/row.ex#L59 is matching correctly and causing the raw SQL result value to be parsed into a Decimal object.
In the OTP 19 builds, you’ll see the following different output:
translate_value value = 1 is_integer = true type = "decimal(2,1)"
yup, matches
tv default clause val = 1 is_integer true type = "decimal(2,1)"
result = 1
which means the same pattern match has somehow failed and it’s falling through (incorrectly) to a default clause later.
I’m stuck. No idea why OTP 18 and 19 behave differently (and only on Ubuntu OS).
Help?
