[Mono-dev] [db|sql]metal using a custom DbSchemaLoader ?

[Jonathan Pryor]

On Mar 8, 2012, at 8:16 AM, Cyrille Chépélov wrote:
>     Would a patch removing the "#if !MONO_STRICT .. public" condition from ISchemaLoader & common implementations be accepted in Mono System.Data.Linq ?

No.

> I notice Mono's S.D.Linq already leaks some bits from DbLinq.Util

Then that's a bug. Mono's System.Data.Linq.dll shouldn't export anything not present in .NET.

What you should instead do is use DbLinq "proper" and bundle it with your app instead of using System.Data.Linq.dll. This will give you proper access to all that DbLinq provides, without making things horribly confusing if/when you run your app on .NET.

>     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.

I'd personally prefer to nuke that type from orbit and instead require that everything use DbSchemaLoader, as that asks the ADO.NET provider to do the database-type <-> managed type mappings, instead of hardcoding it within DbLinq itself. Far saner, and it's what the DbLinq.SqlServer provider does. (The DbLinq.Sqlite provider can also work with it.)

This should also be taken upstream with DbLinq...which is nigh unmaintained at this point. :-(

Yet another of the million things that should be done...

 - Jon