Re: [fpc-devel] Adding a unidirectional dataset to sqldb
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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Adding a unidirectional dataset to sqldb
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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Adding a unidirectional dataset to sqldb
Joost van der Sluis wrote: 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? Maybe for queries with large number of results, that the memory reduction is significant ? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Adding a unidirectional dataset to sqldb
On Wed, 2006-10-18 at 09:10 +0200, Michael Van Canneyt wrote: > > 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 ? No idea. It was Martin's suggestion. > > 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. 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Adding a unidirectional dataset to sqldb
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
Re: [fpc-devel] Adding a unidirectional dataset to sqldb
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.
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
Index: sqldb/sqldb.pp
===
--- sqldb/sqldb.pp (revision 4918)
+++ sqldb/sqldb.pp (working copy)
@@ -62,7 +62,6 @@
);
-{ TSQLConnection }
type
{ TSQLConnection }
@@ -165,25 +164,59 @@
property Params : TStringList read FParams write FParams;
end;
+ { TSQLBasics }
+
+ TSQLBasics = class (TObject)
+ private
+FDBObject: TComponent;
+
+FDatabase: TSQLConnection;
+FTransaction : TSQLTransaction;
+FCursor : TSQLCursor;
+FSQL : TStringList;
+FSQLBuf : String;
+FParams : TParams;
+FLoadingFieldDefs: boolean;
+
+procedure SetDatabase(const AValue : TSQLconnection);
+procedure SetTransaction(const AValue: TSQLtransaction);
+ public
+constructor Create(ADBObject : TComponent); virtual;
+destructor Destroy; override;
+procedure Prepare; virtual;
+Function IsPrepared : Boolean; virtual;
+procedure InternalOpen; virtual;
+procedure InternalInitFieldDefs; virtual;
+
+property Database : TSQLConnection read FDatabase write SetDatabase;
+property Transaction : TSQLtransaction read FTransaction write SetTransaction;
+property Params : TParams read FParams;
+property SQL : TStringlist read FSQL;
+property Cursor : TSQLCursor read FCursor write FCursor;
+ end;
+
+
{ TSQLQuery }
TSQLQuery = class (Tbufdataset)
private
-FCursor : TSQLCursor;
+FSQLBasics : TSQLBasics;
+
+FCursor : TSQLCursor; // r
FUpdateable : boolean;
FTableName : string;
-FSQL : TStringList;
+FSQL : TStringList;// r
FUpdateSQL,
FInsertSQL,
FDeleteSQL : TStringList;
FIsEOF : boolean;
-FLoadingFieldDefs: boolean;
+FLoadingFieldDefs: boolean; // r
FIndexDefs : TIndexDefs;
FReadOnly: boolean;
FUpdateMode : TUpdateMode;
-FParams : TParams;
+FParams : TParams; // r
FusePrimaryKeyAsKey : Boolean;
-FSQLBuf : String;
+FSQLBuf : String; // r
FFromPart: String;
FWhereStartPos : integer;
FWhereStopPos: integer;
@@ -196,12 +229,15 @@
FInsertQry : TSQLQuery;
procedure FreeFldBuffers;
+function GetParams: TParams;
procedure InitUpdates(ASQL : string);
function GetIndexDefs : TIndexDefs;
function GetStatementType : TStatementType;
procedure SetIndexDefs(AValue : TIndexDefs);
+procedure SetParams(const AValue: TParams);
procedure SetReadOnly(AValue : Boolean);
procedure SetParseSQL(AValue : Boolean);
+procedure SetSQL(const AValue: TStringlist);
procedure SetUsePrimaryKeyAsKey(AValue : Boolean);
procedure SetUpdateMode(AValue : TUpdateMode);
procedure OnChangeSQL(Sender : TObject);
@@ -210,6 +246,7 @@
Procedure SQLParser(var ASQL : string);
procedure ApplyFilter;
Function AddFilter(SQLstr : string) : string;
+function getSQL: TStringlist;
protected
// abstract & virtual methods of TBufDataset
Re: [fpc-devel] Adding a unidirectional dataset to sqldb
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. 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Adding a unidirectional dataset to sqldb
On Thu, 2006-10-05 at 08:57 +0200, Michael Van Canneyt wrote: > On Thu, 5 Oct 2006, Joost van der Sluis wrote: > > 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 ... > > An interface does not contain any code, so how would adding an interface > help ? 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Adding a unidirectional dataset to sqldb
On Thu, 2006-10-05 at 07:41 +0200, Martin Schreiber wrote: > On Thursday 05 October 2006 00.38, Joost van der Sluis wrote: > > 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. > > > 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...). I meant one that isn't inherited from TBufDataset, sorry for that mistake. > > 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 ... > > > 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... > 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... ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Adding a unidirectional dataset to sqldb
On Thursday 05 October 2006 08:13, Michael Van Canneyt wrote: > On Thu, 5 Oct 2006, 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 ... > > An interface does not contain any code, so how would adding an > interface help ? No code -> no execution time. Try being faster than that. SCNR. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Adding a unidirectional dataset to sqldb
On Thu, 5 Oct 2006, Joost van der Sluis wrote: > 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 ... An interface does not contain any code, so how would adding an interface help ? Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Adding a unidirectional dataset to sqldb
Joost van der Sluis wrote: 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. Where exactly is the performance problem ? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Adding a unidirectional dataset to sqldb
On Thu, 5 Oct 2006, Joost van der Sluis wrote: > 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 ... An interface does not contain any code, so how would adding an interface help ? Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Adding a unidirectional dataset to sqldb
On Thursday 05 October 2006 00.38, Joost van der Sluis wrote: > 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. > 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...). > 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 ... > 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Adding a unidirectional dataset to sqldb
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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
