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