[Mono-dev] [db|sql]metal using a custom DbSchemaLoader ?
cyrille at chepelov.org
Thu Mar 8 13:16:58 UTC 2012
while trying to apply SqlMetal on a PostGIS database, I received error
messages about unknown SQL data types, some of them being geographic
types, some others being simply type aliases
Apparently, the "DbMetal way" of handling this is to derive from the
DbSchemaLoader (PgsqlSchemaLoader in this case), override SchemaLoader's
MapDbType(), and then invoke dbmetal/sqlmetal
during the DbLinq-to-Mono integration, the "ISchemaLoader /
SchemaLoader" extensibility point has been shut using
MONO_STRICT. The only assembly allowed to know about these
useful types is sqlmetal.exe itself.
Even if you were to build a new ISchemaLoader implementation
from scratch, you can't supply it to sqlmetal anyway, because
you cannot reference the DbLinq.Vendor.ISchemaLoader from Mono's
System.Data.Linq, since it is also internal because of
In effect, you now may use --with-schemaloader to force sqlmetal.exe to
use SqlServerSchemaLoader against an Oracle database, but that's about
all you can do with that option.
Would a patch removing the "#if !MONO_STRICT .. public" condition
from ISchemaLoader & common implementations be accepted in Mono
System.Data.Linq ? I notice Mono's S.D.Linq already leaks some bits from
DbLinq.Util, it doesn't seem to be that big a deal to let ISchemaLoader
escape as well, would it be ?
If such a patch cannot be included, what is the best way to proceed
DbLinq.Vendor.DbSchemaLoader's MapDbType method has a smell in its
"switch/case" statement. Apparently, that has been written much earlier
than the availability of a proper SchemaLoader child class per provider.
So in effect, all type names from all dialects are tested against every
database, regardless of the provider. Wouldn't it be sensible to push
down the type tests into each provider ? I would like to do this.
thanks in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mono-devel-list