[fpc-devel] Adding a unidirectional dataset to sqldb

Martin Schreiber fpmse at bluewin.ch
Fri Oct 20 08:02:03 CEST 2006


On Thursday 19 October 2006 23.02, Joost van der Sluis wrote:
> > You don't need an interface ? What good would that do you ?
>
> No idea. It was Martin's suggestion.
>
Interfaces are usable to do callbacks from the worker class into owner classes 
which don't inherit from a common ancestor or where the common ancestor is 
not under your control. This is the case in MSEgui where I can't modify 
TDataset. In your case there is probably no need for interfaces.

> > Why would it work faster ? The only thing a unidirectionalquery query
> > gives you is less memory requirements, because it needs only 2 buffers.
>
> Less copying around of the buffers.
>
> But I did some tests, it's negligible. I don't see any advantage in this
> worker-class, or the unidirectional query anymore. Maybe that Martin
> still sees some advantages?
>
To have an universal query component without the buffer overhead is definitely 
advantageous. But there is nothing in TSQLQueryUni which can't be done with 
TSQLQuery, so I would finish TSQLQuery first (calculated fields, blob 
support, local live indexes, off line mode, local disk storage, fast RecNo 
access by an linear array of record pointers...).
If you do the internal work with a worker class or with another public visible 
mechanism, it would be easier for external developers to build components 
which don't inherit from TSQLQuery but from TBufDataset or TDataset and use 
the TSQLConnection descendants.
Another possibility: move as as much functionality as you can to 
TSQLConnection and now interfaces are needed to do callbacks into TSQLQuery 
and components which don't inherit from TSQLQuery.

Martin



More information about the fpc-devel mailing list