[Mono-list] SqlMetal to PostgreSQL

[Jonathan Pryor]

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:
> http://npgsql.projects.postgresql.org/license.html

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,
after all...)

I'd love any help in migrating other databases to use
DbSchemaLoader. :-)

 - Jon