Fix SQLite SQL types registrations

[fredericDelaporte]

Invalid types were declared in SQLite dialect, causing cast errors, and having led to an undue hack disabling casting for some types.

Possible breaking change: in order to avoid a floating point division bug losing the fractional part, decimal are now stored as REAL instead of NUMERIC. Both are binary floating point types, excepted that NUMERIC stores integral values as INTEGER. This change may cause big integral decimal values to lose more precision in SQLite.

[fredericDelaporte]

The direct cast was not failing thanks to having previously used the "internal use only" DATETIME type, causing the data provider to do the convert itself. But this was also wrecking casting, and as documented in their chm, this type is not meant for being used outside of the provider itself.

So we need now to do the convert, as are already doing other NHibernate types dealing with DateTime, see TimeType by example.

[mihaicodrean]

Was this really a good call when it comes to Decimal? There's no controlling of the decimals count now, when further casting to string, for example, making reporting a pain, for example. Moreover, the SQLite data types manual specifies the affinity of DECIMAL(10,5) to NUMERIC, not REAL.

[fredericDelaporte]

There was never any actual control of decimal count with SQLite, it has no decimal support. It only has binary floats.

[mihaicodrean]

You're right, I worded it ambiguously. I meant it more like decimals vs. no-decimals, because one now ends up with decimals where there were none previously, due to the replaced NUMERIC:

select sum(cast(FileSize as NUMERIC)) / 1024 / 1024 as MB from Files
=> 14

with REAL:

select sum(cast(FileSize as REAL)) / 1024 / 1024 as MB from Files
=> 14.9871826171875

This is a breaking change, with the workaround to add an extra cast:

select cast(sum(cast(FileSize as REAL)) / 1024 / 1024 as INTEGER) as MB from Files
=> 14

[fredericDelaporte]

This case exploits some very specific behavior of SQLite, where a type that can handle a fractional part behaves as an integer regarding divisions if the provided number is integral. This looks to me as an extreme corner case. Better explicitly use integers where integer behavior is required.