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