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