Many improvements of bigint handling across various DBD::SQLite versions
authorPeter Rabbitson <ribasushi@cpan.org>
Tue, 8 Oct 2013 22:51:25 +0000 (00:51 +0200)
committerPeter Rabbitson <ribasushi@cpan.org>
Wed, 9 Oct 2013 13:14:00 +0000 (15:14 +0200)
commit04ab4eb1fea37384f78394fbff2a463774a0db9c
tree1dee8e6f562aae18c62290e59041b1bee33ae128
parent5342cd1ab95f8cf49a6b5bd87d9d7f8f133c53cc
Many improvements of bigint handling across various DBD::SQLite versions

This started as a patch by ilmari to bind all integers as SQL_BIGINT
as opposed to SQL_INTEGER. While this change itself worked fine, further
testing revealed we never actually bound 'bigint' column types in the
first place. When this was rectified all hell broke loose.

The current situation per DBD::SQLite version

1.29 ~ 1.33:  everything works fine, for large values DBD::SQLite loses
              precision on perl binaries with ivsize == 4 (just like integer
              math within perl itself)

1.35:         Nothing works *regardless* of ivsize. Binding a >32 bit value
              as either SQL_INTEGER or as SQL_BIGINT is impossible (an
              exception is thrown from within DBD::SQLite). DBIC simply strips
              the bindtype altogether and issues an "UPGRADE!" warning.

1.37 ~ 1.40:  Everything works, except for the annoying fact that DBD::SQLite
              issues a spurious 'datatype mismatch' warning when one tries
              to bind a >32 bit value with ivsize == 4. RT#76395
              Warning is silenced for the time being within the guts of DBIC.

On the SQL_INTEGER => SQL_BIGINT change: according to
http://www.sqlite.org/datatype3.html#storageclasses all numeric types are
dynamically allocated up to 8 bytes per individual value. Thus it should be
safe and non-wasteful to bind everything as SQL_BIGINT and have SQLite deal
with storage/comparisons however it deems correct.
Changes
lib/DBIx/Class.pm
lib/DBIx/Class/Storage/DBI/SQLite.pm
t/752sqlite.t