[fpc-devel] Adding a unidirectional dataset to sqldb

Michael Van Canneyt michael at freepascal.org
Wed Oct 18 09:10:55 CEST 2006



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.



More information about the fpc-devel mailing list