I may die alone (at least), but I still don't agree:- 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. - 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. - Sticking to a version will also leave behind the applications who can't upgrade to the version linked by DbLinq.
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? On Mon, Oct 27, 2008 at 10:40, Atsushi Eno <[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]>> 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]> > > msn: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > -- Pascal. jabber/gtalk: [EMAIL PROTECTED] msn: [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 -~----------~----~----~----~------~----~------~--~---
