[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