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.netprovider'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

Reply via email to