Ok now we have enough material to implements the solution.
1) new interface IDriveConnectionCommandProvider (CreateConnection,
CreateCommand)
2) 2 impls of IDriveConnectionCommandProvider; one with creation through
Bytecode the other through DbProviderFactory
3)The ReflectionBasedDriver needs 4 parameters; the newone is the
InvariantName.
if (connectionType == null || commandType == null)
{
then first try to retrieve info from DbProviderFactories: where available
then create appropriate IDriveConnectionCommandProvider
else throws
}
else
{
create appropriate IDriveConnectionCommandProvider (creation through
Bytecode)
}
4) The method CreateConnection() and CreateCommand() will delegate the
responsibility to IDriveConnectionCommandProvider
On Sat, Aug 14, 2010 at 5:59 AM, Jason Dentler <jasondent...@gmail.com>wrote:
> Ingres is "Ingres.Client"
>
> http://code.ingres.com/ingres/main/src/common/dotnet2_win/ingres/factory.cs
>
>
> <http://code.ingres.com/ingres/main/src/common/dotnet2_win/ingres/factory.cs>
>
> On Sat, Aug 14, 2010 at 3:51 AM, Jason Dentler <jasondent...@gmail.com>wrote:
>
>> Yep. The readme for the SQLite provider confirms it.
>> http://sqlite.phxsoftware.com/readme.htm
>>
>> <configuration>
>> <system.data>
>> <DbProviderFactories>
>> <remove invariant="System.Data.SQLite"/>
>> <add name="SQLite Data Provider" invariant="System.Data.SQLite"
>> description=".Net Framework Data Provider for SQLite"
>> type="System.Data.SQLite.SQLiteFactory, System.Data.SQLite" />
>> </DbProviderFactories>
>> </system.data>
>> </configuration>
>>
>>
>>
>> On Sat, Aug 14, 2010 at 3:41 AM, Jason Dentler <jasondent...@gmail.com>wrote:
>>
>>> According to this thread, SQLite is "System.Data.SQLite"
>>>
>>> http://sqlite.phxsoftware.com/forums/t/1886.aspx
>>>
>>> I haven't tested it myself. FYI - It's installed, but didn't create an
>>> entry in machine.config.
>>>
>>>
>>> On Sat, Aug 14, 2010 at 2:28 AM, Frans Bouma <fr...@sd.nl> wrote:
>>>
>>>> > Just posted here:
>>>> http://stackoverflow.com/questions/3481050/invariant-
>>>> > names-for-different-ado-net-providers
>>>> > <
>>>> http://stackoverflow.com/questions/3481050/invariant-names-for-different-
>>>> > ado-net-providers> We'll probably have most of them by tomorrow.
>>>> >
>>>> > Informix is "IBM.Data.Informix", PostgreSQL is "Npgsql"
>>>>
>>>>
>>>> * Adaptive Server Anywhere: "iAnywhere.Data.SQLAnywhere"
>>>> * DB2: "IBM.Data.DB2"
>>>> * Firebird: "FirebirdSql.Data.FirebirdClient"
>>>> * Ingres: (don't know)
>>>> * MySQL: "MySql.Data.MySqlClient"
>>>> * Oracle: ODP.NET: "Oracle.DataAccess.Client"
>>>> * Oracle: MS Oracle: "System.Data.OracleClient"
>>>> * SQLite: (don't know)
>>>> * SQL CE: v3.0: "System.Data.SqlServerCe".
>>>> * SQL CE: v3.5: "System.Data.SqlServerCe.3.5".
>>>> * Sybase ASE: "Sybase.Data.AseClient"
>>>>
>>>> FB
>>>>
>>>>
>>>>
>>>> >
>>>> > Diego
>>>> >
>>>> >
>>>> >
>>>> > On Fri, Aug 13, 2010 at 18:44, Fabio Maulo <fabioma...@gmail.com>
>>>> wrote:
>>>> >
>>>> >
>>>> > Congratulation to both... you are closer...
>>>> > Now I would see the list of InvariantName... a little list
>>>> nothing
>>>> > more
>>>> >
>>>> >
>>>> > On Fri, Aug 13, 2010 at 6:33 PM, Diego Mijelshon
>>>> > <di...@mijelshon.com.ar> wrote:
>>>> >
>>>> >
>>>> > My idea was actually to have an overload with the
>>>> providerName
>>>> > IN ADDITION TO driver/connType/cmdType. That way, if the assembly is
>>>> found,
>>>> > we use it. Otherwise, we fall back to the providerName.
>>>> > The advantage is that users relying on the current
>>>> resolution
>>>> > logic won't notice any changes.
>>>> >
>>>> > Diego
>>>> >
>>>> >
>>>> >
>>>> > On Fri, Aug 13, 2010 at 18:22, Pablo Ruiz
>>>> > <pablo.r...@gmail.com> wrote:
>>>> >
>>>> >
>>>> > Forgetting about 'ConfigurableDriver'.. I think
>>>> we
>>>> can
>>>> > simple modify 'ReflectionBasedDriver' to add two constructors
>>>> overloads,
>>>> one
>>>> > which allows passing a providerName and another one which allows
>>>> passing a
>>>> > providerName and the same three arguments it allows now (assembly,
>>>> > connection class and command class).
>>>> >
>>>> > This way, it will be a matter of each Driver
>>>> using
>>>> one
>>>> > of the three ctors to specify which methods are supported by this
>>>> driver.
>>>> >
>>>> > However, I see at least, one property to make
>>>> drivers
>>>> > supporting both methods, favor DbProviderFactory instead of Reflection
>>>> (of
>>>> > course for compatibility reasons, the default method would be
>>>> Reflection).
>>>> > This way users can switch over to DbProviderFactory just by setting
>>>> some
>>>> > property like 'adonet_dbprovider=true'..
>>>> >
>>>> > Comments?
>>>> >
>>>> >
>>>> > On Fri, Aug 13, 2010 at 9:40 PM, Fabio Maulo
>>>> > <fabioma...@gmail.com> wrote:
>>>> >
>>>> >
>>>> > I would see the list of InvariantName.
>>>> > Have you the list of InvariantName used
>>>> by
>>>> your
>>>> > preferred RDBMS ?
>>>> >
>>>> >
>>>> > On Fri, Aug 13, 2010 at 4:28 PM, Diego
>>>> Mijelshon
>>>> > <di...@mijelshon.com.ar> wrote:
>>>> >
>>>> >
>>>> > We can crowdsource that...
>>>> >
>>>> > Let's see which drivers are
>>>> currently
>>>> > reflection-based:
>>>> > Adaptive Server Anywhere
>>>> > DB2
>>>> > Firebird (two versions of this?)
>>>> > Informix
>>>> > Ingres
>>>> > MySQL
>>>> > PostgreSQL
>>>> > Oracle
>>>> > SQLite
>>>> > SQL CE
>>>> > Sybase
>>>> >
>>>> >
>>>> > In any case, we can have and
>>>> overload in
>>>> > ReflectionBasedDriver that takes a providerName. If that overload is
>>>> not
>>>> > used, nothing changes. That will allow us to port the drivers one by
>>>> one
>>>> > without breaking existing stuff.
>>>> >
>>>> > Diego
>>>> >
>>>> >
>>>> >
>>>> > On Fri, Aug 13, 2010 at 16:05,
>>>> Fabio
>>>> > Maulo <fabioma...@gmail.com> wrote:
>>>> >
>>>> >
>>>> > You can check the
>>>> existence
>>>> of a
>>>> > DLL even without use reflexion.
>>>> > Then we can use the
>>>> InvariantName.
>>>> > Can you provide
>>>> InvariantName for
>>>> > all RDBMS supported by NH ?
>>>> >
>>>> >
>>>> > On Fri, Aug 13, 2010 at
>>>> 3:53
>>>> PM,
>>>> > Diego Mijelshon <di...@mijelshon.com.ar> wrote:
>>>> >
>>>> >
>>>> > You can't have
>>>> your
>>>> cake and
>>>> > eat it too.
>>>> > We can either
>>>> make
>>>> the
>>>> > existing drivers inherit from DbProviderDriver where it makes sense
>>>> (must-
>>>> > install providers, mostly), or have a new set of drivers.
>>>> > ...or we can use
>>>> a
>>>> fallback
>>>> > logic that tries reflection first and, if unsuccessful, goes to DPF.
>>>> >
>>>> > Diego
>>>> >
>>>> >
>>>> >
>>>> > On Fri, Aug 13,
>>>> 2010
>>>> at
>>>> > 15:27, Fabio Maulo <fabioma...@gmail.com> wrote:
>>>> >
>>>> >
>>>> > That
>>>> solution is the
>>>> > solution of Microsoft and give you the ability to work with multiple
>>>> > versions of the same assembly installed in the GAC.
>>>> > The
>>>> usage of
>>>> > DbProvider is not a problem but shouldn't be so complicated as
>>>> proposed.
>>>> It
>>>> > should be completely transparent; the NH users should have 0 changes
>>>> to
>>>> work
>>>> > with or without DbProvider.
>>>> >
>>>> >
>>>> > On Fri,
>>>> Aug
>>>> 13, 2010
>>>> > at 3:22 PM, Diego Mijelshon <di...@mijelshon.com.ar> wrote:
>>>> >
>>>> >
>>>> >
>>>> I
>>>> see... I
>>>> > didn't know that.
>>>> >
>>>> However,
>>>> > there's a problem with that solution: I lose version independency.
>>>> >
>>>> That
>>>> problem
>>>> > is fixed by the DbProviderDriver without introducing any problems that
>>>> I
>>>> can
>>>> > think of.
>>>> >
>>>> >
>>>> Diego
>>>> >
>>>> >
>>>> >
>>>> >
>>>> On
>>>> Fri, Aug
>>>> > 13, 2010 at 14:23, Fabio Maulo <fabioma...@gmail.com> wrote:
>>>> >
>>>> >
>>>> >
>>>> You
>>>> > don't have to.
>>>> >
>>>> In our
>>>> > tests you can see how redirect a partial assembly-name.
>>>> >
>>>> >
>>>> >
>>>> On Fri,
>>>> > Aug 13, 2010 at 12:15 PM, Diego Mijelshon <di...@mijelshon.com.ar>
>>>> wrote:
>>>> >
>>>> >
>>>> >
>>>> > This is a great patch, we currently have to copy
>>>> > IBM.Data.Informix.dll everywhere.
>>>> >
>>>> >
>>>> >
>>>> > I can create the DPF-based Informix driver if this gets
>>>> included.
>>>> >
>>>> >
>>>> > Diego
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > On Fri, Aug 13, 2010 at 11:41, Pablo Ruiz <pablo.r...@gmail.com
>>>> >
>>>> > wrote:
>>>> >
>>>> >
>>>> >
>>>> > Hi,
>>>> >
>>>> >
>>>> > By reading the details at http://216.121.112.228/browse/NH-1378
>>>> looks
>>>> > like this was an old request (1.2.1 days) which has been considered
>>>> already.
>>>> > How ever (surelly due to time constraints ;)) this is still an open
>>>> issue,
>>>> > which may be considered now for NH3.
>>>> >
>>>> >
>>>> > I have a couple of classes implementing a base driver using
>>>> > DbProviderFactory, and I have attached them to the jira issue, so
>>>> anyone
>>>> can
>>>> > review them... This one are copied from my own project, but they are
>>>> simple
>>>> > enought to get an starting point from which a discussion can be
>>>> started.
>>>> >
>>>> >
>>>> > The point behind this issue (for me) it's mainly mono
>>>> compatibility,
>>>> > as mono does not implement 'BindingRedirect' support, and as such, the
>>>> only
>>>> > way of making NH work it's by placing the ado.net provider's assembly
>>>> at
>>>> bin
>>>> > folder, which in some deployments it's far from perfect.
>>>> >
>>>> >
>>>> > As such, if having alternate driver implementations using
>>>> Reflection
>>>> > (current one) and DbProviderFactory (the alternate one) looks great
>>>> for
>>>> > Fabio & co, I can provide fully-functional patches against trunk, just
>>>> letme
>>>> > know about it.. ;)
>>>> >
>>>> >
>>>> > Saludos.
>>>> >
>>>> > Att. Pablo
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> --
>>>> >
>>>> Fabio
>>>> > Maulo
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Fabio
>>>> Maulo
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Fabio Maulo
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Fabio Maulo
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Fabio Maulo
>>>> >
>>>> >
>>>> >
>>>>
>>>>
>>>>
>>>
>>
>
--
Fabio Maulo
