[Mono-list] SqlMetal to PostgreSQL
jonpryor at vt.edu
Mon Feb 8 10:59:41 EST 2010
On Sun, 2010-02-07 at 21:36 -0500, Abe Gillespie wrote:
> I had brought this issue up a while back along with the "money" type.
> And although the issue was marked as fixed, it seems as though there
> was a major refactoring and now I cannot find the source file that
> included these type mappings.
Odd; I don't know of any large refactoring that would break or otherwise
move the type mappings...
> My question to the developers: is there no way to integrate this type
> mapping stuff with the NpgsqlTypes.* classes? I see that the
> NpgsqlTypes.NpgsqlTypesHelper is an internal class, but can't the
> source code be cannibalized somehow? I'm now license expert, but it
> seems permissible enough:
There is, in fact, a "better" way: DbLinq.Vendor.DbSchemaLoader.
Instead of hardcoding a "SQL type" to managed type mapping, we ask the
DbConnection for it's DataTypes table, which provides the SQL type to
managed type mapping. (Aka, "Why replicate and hard-code what the
DbConnection already knows?")
The problem is threefold:
(1) DbSchemaLoader is a new type (currently only used by
SqlServerSchemaLoader, though SQLite support is also present for
test purposes -- but not the default)
(2) use of DbSchemaLoader will require changes to each existing
SchemaLoader implementation, and such changes may break things
(as I can only easily test SQL Server and SQLite)
(3) Type mappings may change.
Specifically, with the SQLite provider the INTEGER SQL type is mapped to
`int` when using SchemaLoader.MapType, but becomes a `long` when we ask
SqliteConnection for the appropriate type. This may or may not be
desirable, but can certainly constitute a "break" from previous
releases. (Which really shouldn't be a concern, given how many other
things are likely to change from release to release -- DbLinq isn't 1.0,
I'd love any help in migrating other databases to use
More information about the Mono-list