[Mono-dev] SxSVersion third stage: The vendor's problem

[Atsushi Eno]

(Forwarding to mono-devel-list as well.)

If DBLinq project is to drop any other DB support than for SQL Server in
System.Data.Linq.dll, I'm OK with that, since Mono community proved that 
it does
not welcome improvements over compatibility stack anyways.

Even if mono community started to want extensiblity, no worries. We 
could make
some changes to add support for other databases, probably by adding
Provider->Vendor resolution hack and/or adding external assemblies to 
support
other DBs, when importing DBLinq tree to mono (mcs) build tree.

I don't hesitate to fork some code in mono tree, as long as it could be 
almost
harmlessly done. At least we always give our feedback on any desired 
changes,
as we used to do :)

Atsushi Eno

This message is an official statement from the position and  does not 
represent
the position of myself.

Pascal Craponne wrote:
> Hi Pablo,
>
> yes, that's the idea (I made minor changes this morning, I think they 
> are easy to understand), an IVendor implementation is identified by 
> its attribute.
>
> I placed all providers in x.Data.Linq.SqlClient namespace, exactly 
> like there are in the .NET specifications (and I just created now 
> Sql2000Provider and Sql2005Provider).
> There are also other providers, such as MySqlProvider, OracleProvider, 
> and they are PUBLIC.
> Now we have two options (not three) for MONO_STRICT:
> 1. We want to support other databases and then we keep those providers 
> public and in System.Data.Linq assembly
> 2. We don't want to keep those providers public and then we remove 
> support for other databases
>
> To me the choice is obvious. Make yours :)
>
> Pascal.
>
> On Sat, Jul 12, 2008 at 00:29, Pablo Iñigo Blasco <pibgeus at gmail.com 
> <mailto:pibgeus at gmail.com>> wrote:
>
>     Hi Pascal, thank for answering.
>
>     On Fri, Jul 11, 2008 at 20:02, Pascal Craponne <picrap at gmail.com
>     <mailto:picrap at gmail.com>> wrote:
>     "I don't like much your implementation of
>     VendorFromProviderType(), but we may change it later (with
>     reflection and assemblies scan), and please don't create any
>     .Strict.cs file. If it is good for Mono, it is good for DbLinq :)"
>
>     I have seen your idea, it looks much better(and a strict.cs isn't
>     needed) :-). Nonetheless I have a couple of questions:
>     -Why isn't needed anoter assembly that contains providers types in
>     strict mode?
>     - How does the user of System.Data.Linq.dll do to specify wich
>     vendor he want to use? As far as I understood your proposal is to
>     mark with the providerattibutte both: user's "specific domain
>     datacontext" and vendors implementations, isn't it?
>     When both providerattributte's Type property match we would get
>     the vendor to use, right?
>
>     Finally you said:
>     "if we use reflection for method above, then there is no need to
>     reference all drivers in a single assembly."
>     Where are located those "providers classes" for the strict mode
>     vendors?
>     I think we need to have those providers types in an external
>     assembly since they must be public (for the user's datacontext)
>     and we shouldn't change System.Data.Linq API.
>
>     What haven't I understood?
>
>
>     "Regarding Mono, you can place all vendors code in the
>     System.Data.Linq.csproj."
>     I did it. It was the main idea of the embeded approach.
>
>
>     "I committed a version implementing VendorFromProviderType()
>     (please rename this method, there's no verb in it)."
>     Ok. I agree.
>
>     Regards.
>
>     PS:
>     Excuse me about spelling mistakes, I am from a mobile phone.
>
>
>
>
>
> -- 
> Pascal.
>
> jabber/gtalk: pascal at jabber.fr <mailto:pascal at jabber.fr>
> msn: pascal at craponne.org <mailto:pascal at craponne.org>
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google 
> Groups "DbLinq" group.
> To post to this group, send email to dblinq at googlegroups.com
> To unsubscribe from this group, send email to 
> dblinq-unsubscribe at googlegroups.com
> For more options, visit this group at 
> http://groups.google.com/group/dblinq?hl=en
> -~----------~----~----~----~------~----~------~--~---
>