On Tue, 17 Oct 2006, Joost van der Sluis wrote:
> On Fri, 2006-10-06 at 07:51 +0200, Martin Schreiber wrote: > > On Thursday 05 October 2006 22.41, Joost van der Sluis wrote: > > > > > Now I'm thinking about using an interface, to avoid double code. But I > > > > > don't know what effect that has on run-time performance. I mean, the > > > > > idea was to make if faster ... > > > > > > > > A very good idea! It can then be implemented by a common worker class. > > > > TSQLConnection and TSQLTransaction should be independent of TSQLQuery > > > > and > > > > TSQLQuery should get its own unit. > > > > > > Can you explain to me how I should construct this worker-class? As > > > Michael said, my solution won't work... > > > > > If TSQLConnection or TSQLTransaction need callbacks into TSQLQuery and > > "TSQLQueryUni" do it by an corba interface (at the first glance I didn't > > see > > any). > > To implement the common functions of TSQLQuery and TSQLQueryUni use a > > "worker > > class" which does callbacks by an corba interface. > > Ok, I tried to implement this. I still don't understand why I should > need an interface for this, though. You don't need an interface ? What good would that do you ? > > Attached is a patch that does this. It's work in progress, TSQLQuery > doesn't work with this patch, but the TSQLUnidirectionalQuery does. At > least, a basic select works... > > But I wanted to make things faster. I'm not feeling comfortable with > creating more wrapper-class layers, more complexity, for nothing, if it > doesn't result in any speedup. Why would it work faster ? The only thing a unidirectionalquery query gives you is less memory requirements, because it needs only 2 buffers. Michael. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
