Mmm, never mind :( I was under the impression that the assembly of the redirected version does not have to exist, but maybe it does.
Atsushi Eno Atsushi Eno wrote: > Hello, > > Pascal Craponne wrote: >> I may die alone (at least), but I still don't agree: > > Well, it is all about "when we couldn't prove the target > vendor/provider after iterating assemblies in the current domain. > > It is not to stick to specific driver (at least what I intended). > Discussed details below. > > But before digging in depth, I'd like to confirm whether we take the > approach to check assemblies in the current domain. Right now > MONO_STRICT doesn't work at all for connectionString-based use due to > the current assembly load strategy. > > >> - Sticking to a driver will cause problems where there are two driver >> implementations, such as Oracle drivers, where there are two different >> implementations, MS and ODP. > > I'm curious - can/should they be the same implementation while the > "vendors" are different? Is it still valid when we start to consider > creating IDbConnection instance from connection string i.e. how can > we distinguish a connection string for OracleClient and for ODP.NET > within one vendor API? Add another connection string item such as > "OracleDriver=ODP" ? > >> - Sticking to a version will require DbLinq to be built and integrate >> each new version. Today DbLinq supports 7 databases. How many releases >> will it imply each year? How many releases when DbLinq will support 10 >> databases? Too many. > > Note that I didn't suggest to "actually" stick to specific versions > of database drivers. As I wrote in the previous message, they should > be redirected to newer versions as long as the driver vendors ship > policies. Or you could even put assembly configuration for dblinq. > That is, for each <bindingRedirect> element you just give the oldest > supported version of the driver like: > > <dependentAssembly> > <assemblyIdentity name="MySql.Data" publicKeyToken="(snip)" > culture=""/> > <bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535" > newVersion="(the oldest supported version" /> > </dependentAssembly> > > seealso http://msdn.microsoft.com/en-us/library/9w519wzk(VS.71).aspx > > It'd happen just once. I don't think there really is such a task to > manage every driver every year, unless they became very different > (probably like Npgsql -> Npgsql2, where we should really care, > at least the assembly name has changed). > >> - Sticking to a version will also leave behind the applications who >> can't upgrade to the version linked by DbLinq. > > So it won't happen, unless the driver assembly name changes (and > even it might not happen as you seem to have some magic to have > OracleClient and ODP.NET coexist within a vendor implementation). > >> Each actor has its responsibility and it's better if the application has >> the responsibility to assemble all parts and make a consistent result. >> >> Atsushi, are you talking in your message about loading vendor or >> database driver? > > Both. But note that under MONO_STRICT I don't need any trick for > loading vendors ;-) > > Atsushi Eno > > >> On Mon, Oct 27, 2008 at 10:40, Atsushi Eno <[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]>> wrote: >> >> >> Actually, personally I'm positive to include version dependency >> on those driver assemblies. The reasons are: >> >> - It is the database driver vendor who claims that a future version >> of the assembly is compatible with older versions of the driver or >> not (by "publisher policy file" i.e. policy.*.*.dll in general). >> - Usually a user (dblinq here) should depend on specific version of >> the dependency assemblies in each version of his or her application >> - A user (we) can finally determine whether a future version of the >> assembly is compatible with older versions in respect to his or her >> application. It can be specified by our assembly configuration >> (/configuration/runtime/assemblyBinding/dependentAssembly). >> >> While we would likely want to avoid loading "duplicate" assemblies >> (not precisely though; they have different versions), we can first >> iterate Assemblies in CurrentDomain, and then try Assembly.Load() with >> fully qualified name. Then users don't have to add extra code to load >> the driver assembly in prior to use dblinq. >> >> Adding custom configuration section may also look like a solution, if >> we want to let users to make first decision on which Type should be >> regarded as the target driver (it is typical scenario). But the problem >> here is that it works only when the dependent assemblies MUST exist >> *while proving the target driver*. Otherwise it will raise an error >> saying that the configuration system cannot find the target Type. >> (Am I understanding the situation correctly? I'm unsure.) >> >> Atsushi Eno >> >> >> Pascal Craponne wrote: >> > What options do we have for the database driver (the ADO one)? >> > How to make the guess? Shall be make a choice given another >> parameter in >> > the connection string? Shall DbLinq also scan the AppDomain, and ask >> > vendor if any found IDbConnection is suitable (this condition is not >> > sufficient, we also need to dig more). >> > >> > On Fri, Oct 24, 2008 at 22:43, Jiri Moudry <[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]> >> > <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> wrote: >> > >> > >> > Pascal, Astushi - Ohayo gozaimasu & Bon soir, >> > seems that both of you like scanning the AppDomain for the >> IVendor >> > class and the IDbConnection implementation. >> > I like it also, because it results in fewer assumptions and >> shifts >> > responsibility to the user. Should we go ahread with that >> approach? >> > >> > >> > >> > >> > >> > -- >> > Pascal. >> > >> > jabber/gtalk: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >> <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> >> > msn: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >> <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> >> > >> > >> > > >> >> >> >> >> >> >> -- >> Pascal. >> >> jabber/gtalk: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >> msn: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >> >> > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DbLinq" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/dblinq?hl=en -~----------~----~----~----~------~----~------~--~---
