@@ -119,7 +119,7 @@ module MyCustomMappings =
119119```
120120
121121You can have as many classes as you want defining static custom mappings. But you can't split the mapping for a * single
122- usertype * across multiple classes. ` ToPrimitive : Foo -> string ` has to be defined in the * same* class as `FromPrimitive
122+ UserType * across multiple classes. ` ToPrimitive : Foo -> string ` has to be defined in the * same* class as `FromPrimitive
123123: string -> Foo` for the mapping to be valid.
124124
125125## Using the mapped types
@@ -261,7 +261,7 @@ module ExampleOverrides =
261261 let unixEpoch = DateTime(1970,1,1)
262262 type System.DateTime with
263263 member this.ToPrimitive() : int64 = int64 (this - unixEpoch).TotalSeconds
264- static member FromPrimitive(i : int64) = unixEpoch + TimeSpan.FromSeconds(i)
264+ static member FromPrimitive(i : int64) = unixEpoch + TimeSpan.FromSeconds(float i)
265265
266266 // change Guid to store as a string instead of a byte[] blob
267267 type System.Guid with
@@ -274,20 +274,20 @@ UserTypes, when it's a builtin type you've re-mapped, you *don't* have to be cas
274274queries. That would just be far too confusing if typing ` DateTime ` applied your overridden methods but ` datetime `
275275didn't!
276276
277- ### Decimal and DateTimeOffset on SQLite
277+ ### Supporting Decimal and DateTimeOffset on SQLite
278278
279- I especially recommend doing this for the SQLite backend if you'd like to use ` decimal ` or ` DateTimeOffset ` . By default
280- these types will throw an exception if used with a SQLite backend because I couldn't think of an acceptable * default*
281- way to support them. For decimal, if we mapped to ` REAL ` you would lose the precision and basetenity of ` decimal ` . The
282- only lossless way to store and retrieve a ` decimal ` value would be in a SQLite ` BLOB ` or ` TEXT ` column, but then
283- mathematical operators would break or silently decay to binary floating point.
279+ Custom mapping can help you with the SQLite backend if you'd like to use ` decimal ` or ` DateTimeOffset ` . By default these
280+ types will throw an exception if used with a SQLite backend because I couldn't think of an acceptable * default* way to
281+ support them. For decimal, if we mapped to ` REAL ` you would lose the precision and base-10 math of ` decimal ` . The only
282+ lossless way to store and retrieve a ` decimal ` value would be in a SQLite ` BLOB ` or ` TEXT ` column, but then mathematical
283+ operators would break or silently decay to binary floating point.
284284
285285Likewise with ` DateTimeOffset ` , the obvious choice would be to use ` .ToString("o") ` like we do with DateTime, but then
286- comparisons and equality would produce unexpected results. The below expression evalutes TRUE in SQLite using string
287- comparison, but should be FALSE comparing the actual moment in time the two ` DateTimeOffset ` types represent. The UTC+0
286+ comparisons and equality would produce unexpected results. The below expression evaluates FALSE in SQLite using string
287+ comparison, but should be TRUE comparing the actual moment in time two ` DateTimeOffset ` types represent. The UTC+0
288288one is a minute before the UTC-4 one.
289289
290- ` '2026-06-07T21:16 :00.0000000-04 :00' > '2026-06-08T01:15 :00.0000000+00 :00' `
290+ ` '2026-06-08T01:15 :00.0000000+00 :00' < '2026-06-07T21:16 :00.0000000-04 :00' `
291291
292292If you understand the problem space and have chosen storage format where the tradeoffs work for * your needs* , mapping
293293these types can be the right call.
0 commit comments