Hi all,

I have plans to add an unidirectional dataset/query to sqldb. Thus one that isn't inherited from TDataset. This to improve performance, for for example cgi-like programs, in which iterating back and forth through a database isn't necessary.

But while working on this, I discovered that very much code from TSQLQuery could be exactly copied to this new class.

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 ...

Any thoughts on this?

regards,
Joost.

It should inherit from TDatset but not from TBufDataset IMHO to allow to use the existing DB components in Lazarus and MSEgui (persistent fields, data display widgets, field->parameter link, calculated fields...).

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.
I use not reference counted (corba style) interfaces very often in MSEide+MSEgui and I am happy with them. I would even be more happy without Mantis 6036 and 6690...

Martin

Where exactly is the performance problem ?

Micha

An interface does not contain any code, so how would adding an interface help ?

Michael.

An interface does not contain any code, so how would adding an interface help ?

Michael.

TBlobField.SaveToStream and LoadFromStream dont work in Windows (with tdbf) Can somebody tale a look at this ? its very importend for my actual project.

regards
Christian

No code -> no execution time. Try being faster than that. SCNR.

I have an strange Issue here with tdbf and master/detail. I have 2 sorts of Master/Detail relationships in this project. at first with FIELD based indexes:
At example i haven an customers table and and customercontact table. both have an Field ACCOUNTNO over what the master / detail relationship is added. this field is indexed in customercontact.

Master/Detail works only sometimes. Sometimes it works great and sometimes i see all records in the customercontact table.
I cant see any differences. when i delete the tables after it hasnt been worked and recreate them it works and sometimes the other direction.

The same bug occours with indexes with more fields. But there it occours oftener. I have some tables with indexes in this way :

AddIndex('ARTICLENO','ARTICLENO+VERSION+LANGUAGE',[ixPrimary,ixUnique]);
MasterFields := 'ARTICLENO+VERSION+LANGUAGE';

there this problem occours very often.
I use tdbf from fpc svn.

regards
Christian

Always make a bug report (either at fpc ), and include an example test (project) that will reproduce the problem.

Micha

ok, i will try to make it reproduceable

I meant one that isn't inherited from TBufDataset, sorry for that mistake.

Can you explain to me how I should construct this worker-class? As Michael said, my solution won't work...

I use not reference counted (corba style) interfaces very often in MSEide+MSEgui and I am happy with them. I would even be more happy without Mantis 6036 and 6690...

You're right. It was probably late last night. ;)

Do you have another solution? Plugwash suggested to use an include file, with some macro's defined. That could work, but it's a little but ugly, imho.

Other ideas?

Joost

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. See for an example tdscontroller and tmsesqldb in MSEgui which I used to implement different DB workarounds and extensions.

http://svn.sourceforge.net/viewvc/mseide-msegui/trunk/lib/common/db/ msedb.pas, msesqldb.pas.

Martin

Ok, I tried to implement this. I still don't understand why I should need an interface for this, though.

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.

Good side-effect is, that I could make a parent for TSQLBasics 'worker- class' which could be used by external sqldb-add-in's. As Michael, Bram and I discussed before.

But for now, I'm curious what you guys find the work done in the attachment, before I go on with this...

Regards,
Joost

You don't need an interface ? What good would that do you ?

Why would it work faster ? The only thing a unidirectionalquery query gives you is less memory requirements, because it needs only 2 buffers.

Michael.

No idea. It was Martin's suggestion.

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?

Joost

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.

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

Maybe for queries with large number of results, that the memory reduction is significant ?

Micha

Martin Schreiber wrote

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.

Or callbacks (closures).

Micha