[Mono-dev] SxSVersion third stage: The vendor's problem
Atsushi Eno
atsushi at ximian.com
Sat Jul 12 12:08:24 EDT 2008
Hey,
Pablo wrote a nice summary on the choices and effects:
http://groups.google.com/group/dblinq/msg/83e5b83b14cb9289
I very much agree on that it would be nicer to avoid extra work,
as long as possible. The problem is that we have to compromise
at some points. In this case, extensibility is given up for
the sake of .NET compatibility (to not expose extra types in
System.Data.Linq.dll) and minimizing changes in dblinq code base.
Atsushi Eno
Rodrigo Kumpera wrote:
> I think one aspect we should always keep in mind is make it easier for
> all sides to work together.
> We are not many and avoiding duplicate work is a good idea any time.
>
> Atsushi, your email doesn't talk on this subject, but how this decision
> affect the overall work
> that will have to be done by the teams involved?
>
> Cheers,
> Rodrigo
>
> On Sat, Jul 12, 2008 at 6:14 AM, Atsushi Eno <atsushi at ximian.com
> <mailto:atsushi at ximian.com>> wrote:
>
> (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>
> > <mailto: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>
> > <mailto: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>
> <mailto:pascal at jabber.fr <mailto:pascal at jabber.fr>>
> > msn: pascal at craponne.org <mailto:pascal at craponne.org>
> <mailto: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
> <mailto:dblinq at googlegroups.com>
> > To unsubscribe from this group, send email to
> > dblinq-unsubscribe at googlegroups.com
> <mailto:dblinq-unsubscribe at googlegroups.com>
> > For more options, visit this group at
> > http://groups.google.com/group/dblinq?hl=en
> > -~----------~----~----~----~------~----~------~--~---
> >
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> <mailto:Mono-devel-list at lists.ximian.com>
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
More information about the Mono-devel-list
mailing list