Add proper support for Word64

[erikd]

Previously when the schema used Word64 as the column type, Persistent
would would use SqlInt64 as the SQL representation which means that
Word64 values above maxBound :: Int64 would be stored as negative
values in the database. That is fine for a database only accessed from
Haskell but is a pain in the neck when the database is used as an
interop layer for other languages.

This commit fixes these issues by adding SqlWord64 and PersistWord64.

Closes: #1095

This works in my application. Specifically it fixes IntersectMBO/cardano-db-sync#163 but has not been tested beyond that. I have not fixed or even tested this for the other database back ends. I will see what CI says.

• Documented new APIs with Haddock markup
• Added @since declarations to the Haddock

After submitting your PR:

• Update the Changelog.md file with a link to your PR
• Bumped the version number if there isn't an (unreleased) on the Changelog
• Check that CI passes (or if it fails, for reasons unrelated to your change, like CI timeouts)

[erikd]

@parsonsmatt Once I fix all the CI errors is there anything else required to get this merged?

[parsonsmatt]

I'm going to be out for the next week so you may want to ping another maintainer if you want it in soon :) I generally trust your judgement and I don't expect there will be any issues aside from the checklist.

[erikd]

Currently getting the following failure in CI:

 src/LargeNumberTest.hs:25:3: 

  1) Large Numbers preserves their values in the database

       uncaught exception: PersistException

       PersistMarshalError "Couldn't parse field `word64` from table `number`.
       Failed to parse Haskell type `Word64`; expected integer from database, but received:
       PersistDouble 1.8446744073709552e19. Potential solution: Check that your database schema matches your
       Persistent model definitions."

I am not even sure which database backend this is coming from.

However 1.8446744073709552e19 is slightly more than maxBound :: Word64 which is why that test fails.

Clues?

[erikd]

How does one run the tests? I use Postgres and was trying cabal test persistent-postgresql and I get:

Test suite test: RUNNING...
test: libpq: failed (fe_sendauth: no password supplied
)
Test suite test: FAIL

There is a shell script at persistent-postgresql/test-settings.sh but that references a Haskell file test-settings.hs that does not exist.

[parsonsmatt]

I think the testing setup relied on older behavior of postgres authentication. It should probably require a specific user and a password.

[parsonsmatt]

is fromIntegral here a no-op?

[parsonsmatt]

Suggested change

	| SqlWord64 -- @since 2.11.0
	| SqlWord64 -- ^ @since 2.11.0

so it is a proper doc comment

[parsonsmatt]

Suggested change

	| PersistWord64 Word64 -- @since 2.11.0
	| PersistWord64 Word64 -- ^ @since 2.11.0

[parsonsmatt]

I wonder if this is what's going on with the failing test you're finding. Based on this saying that INTEGER is (at most) an 8 byte size, I'd expect that maxBound :: Word64 would be troublesome.

[parsonsmatt]

Which, uh. Hm. Would suggest that the current behavior is Correct, since the test isn't failing right now, at least for SQLite.

[parsonsmatt]

@erikd So in my investigation on this problem, it looks like there isn't going to be a way to get SQLite to have the "proper" behavior - the INTEGER type in SQLite just doesn't support values that large, so the negation trick is the only way to make it work out. I think we can just back that behavior out to the older behavior, throw a doc comment somewhere as to why sqlite doesn't use the Word64 constructor, and get this out the door 😄