This thread is getting longer each day (and we're now probably out of its
original scope).
Here's my concrete suggestion for implementation:
Needs:
- we need to optionally specify a IVendor and a IDbConnection
- since we stick to MS.NET API, the only workaround we have is to use the
connection string
Specifications:
- for both (IVendor and IDbConnection), use more or less qualified type:
* more qualified type when the assembly isn't loaded, so we need to use a
type name+assembly to find and load it
* average qualified type when the assembly is already loaded, so we need
here only the qualified type
* less, like a vendor ID, if the vendor is a well-known vendor, and is
already loaded in memory (optional, let me know if you like it)
- Today the IVendor is identified by "DbLinqProvider", I suggest to rename
it "DbProvider" (because of mono) and use "DbConnection" to identify the
IDbConnection
Examples:
- fully qualified vendor and connection
"DbProvider=DbLinq.PostgreSql.PgsqlVendor, DbLinq.PostgreSql;
DbConnection=Npgsql.NpgsqlConnection, Npgsql; ..."
- partially qualified: "DbProvider=DbLinq.PostgreSql.PgsqlVendor;
DbConnection=Npgsql.NpgsqlConnection; ..."
- ID qualitifed: "DbProvider=PostgreSQL; DbConnection=PostgreSQL; ..."
Implementation:
- Create or extend the Util.TypeLoader utility class to find a type or load
it (today the class doesn't load assemblies)
- Use it for both IVendor and IDbConnection
- Regarding the ID qualification, this requires:
* adding some attribute to vendor implementations, so we could mark
vendors with an additional attribute such as "[VendorID("PostgreSQL")]"
* AppDomain scan
I'm not the sure the ID thing is a good one, at least in the current
solution.
So. Who agrees, who disagrees? Jiri, how long to you think it will take to
change?
Thanks,
Pascal.
On Thu, Oct 30, 2008 at 09:04, Atsushi Eno <[EMAIL PROTECTED]> wrote:
>
> 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<http://msdn.microsoft.com/en-us/library/9w519wzk%28VS.71%29.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]>
> >>
> >>
> >
> >
> > >
> >
>
>
> >
>
--
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
-~----------~----~----~----~------~----~------~--~---
