Board index » delphi » Re: What I would Like to See in Delphi

Re: What I would Like to See in Delphi


2008-06-07 07:53:26 PM
delphi137
Nick Hodges (CodeGear) writes:
Quote
That I'd definitely not do.

We've actually added

type string = UnicodeString;

so that UnicodeString is the default string.
Though that helps to port ansi code to Delphi 2008 it does not solve
my problem...
I have code that is *already* unicode enabled and I must share these units
between Delphi 2007 and 2008 for the foreseeable future so I must
remain explicit about unicode and ansi strings.
I'd just like to have the speed advantage of "unicodestring" when compiled
under D2008.
--
Arthur Hoornweg
(In order to reply per e-mail, please just remove the ".net"
from my e-mail address. Leave the rest of the address intact
including the "antispam" part. I had to take this measure to
counteract unsollicited mail.)
 
 

Re: What I would Like to See in Delphi

Yannis writes:
<snip>
Ok, perhaps is better to not to concentrate on a presumable solution,
perhaps is better to express clearer our needs:
Use case:
We have an n-Tier layer already set up. Let it be on Server-A a SQL
database which have (among other things) a table T1 with 9 fields: F1,
F2,..., F9. We have a communication layer to Server-A composed from a
TSQLConnection component (conMain), TSQLDataSet component called tblMain
connected to above TSQLConnection with the following properties:
tblMain.SelectSQL: 'Select * from T1';
tblMain.EditSQL: 'Update T1 set F1=:F1, F2=:F2, ... where PK=:PK;'
tblMain.InsertSQL: 'Insert into T1 (F1, F2,...) values (:F1, :F2..);'
tblMain.DeleteSQL: 'Delete from T1 where PK=:PK';
We have a TDataSource component (dsoMain) with:
dsoMain.DataSet:=tblMain;
And some UI components: DBGrid1.DataSource:=dsoMain; (etc.)
When we issue tblMain.Open then what's happening? (assuming that the
connection component is ok)
(in very simplified terms)
tblMain opens a transaction and executes the query on Server-A and
fetches from there a data packet consisted from, let's say, 20 records
and fills the DBGrid1's needs through the dsoMain. tblMain also has a
RecNo property which gives us the current record. If you add/edit/delete
records in DBGrid1 all the queries to Server-A will be handled
automatically for you. The same stands for the buffer management when
you play with Arrow keys or PgUp/PgDn in DBGrid1 to scroll in the grid.
The records are fetched dynamically in chunks, as needed from Server-A.
In some implementations the 'chunk' can be one record only. (If you want
to dig in the 'dialogs' between a data set and data aware controls you
can have a look at TDataLink descendants). Note that even if DBGrid1 can
have a small buffer of records copied from tblMain, the speed of this
copy operation (tblMain->DBGrid1) is higher in many orders in magnitude
compared with the speed of the fetch operation from Server-A which
happens in tblMain (Server-A->tblMain).
The problem here is that the buffer management part (the 'fetch' - the
slow part) isn't separated from the navigational part (which is quick).
So, in the present situation, if we have many cursors we need many
'parallel' fetch engines. (ie. many 'brothers' of tblMain) which leads
to performance penalty.
The Delphi team saw this and they have already the TClientDataSet for
this job, but:
0. For more details read my post to 'delfo' higher in this subthread :-)
...here I will post only another one which I didn't made very clear there:
1. It has its own buffer which leads to data desynchronization between
the clones. (among other things - see my previous post)
So, we need:
A TDataSet descendant (not a TDataSource, even if I also proposed it,
now I think that we'll mix class responsibilities if we'll derive it
from TDataSource) which will work like this:
Let it be MyClone1, MyClone2, ... the instances of the new component:
MyClone1.ClonedDataSet:=tblMain; //attach them
MyClone2.ClonedDataSet:=tblMain;
dsoMain.DataSet:=MyClone1; //DBGrid1 will look here
Let's add another UI component: DBGrid2 and a TDataSource called dso2:
dso2.DataSet:=MyClone2;
DBGrid2.DataSource:=dso2;
Let us accept that the tblMain buffer is 20 records. Also in the
following time line 'Program:' means what the developer writes and
'Operations done:' what the framework does 'behind the scenes':
We'll open all the data sets:
Program:
conMain.Connect;
tblMain.Open;
MyClone1.Open;
MyClone2.Open;
Operations done: Fetch from Server-A 20 records. Request Rec#1 to
MyClone1. Request Rec#1 to MyClone2. (If they're willing to implement a
shared buffer then it will be /very/ fast, just a matter of pointers -
but I doubt that they will, there may be quirks there - ie. they must
expose a standard buffer interface in TDataSet like an array of records
- something like in .NET). Also, if the grids will ask for more records,
these records will be 'passed' to them (if the internal mechanism of
DBGrids wants to copy the records or whatever TCloneDataSet class
doesn't know) through the clones. Let's say that both grids asks for 10
records, so 10 records are transferred through the clones to them.
Program:
MyClone1.RecNo:=14;
Operations done: Request Rec#14 to MyClone1 + 9 records due of DBGrid1's
request. This triggers a fetch from Server-A for only 4 records (the
records Rec#14 till Rec#20 were already in tblMain's buffer - so only
the Rec#21 till #24 will be fetched from server). The DBGrid1 is updated
accordingly.
Program:
MyClone2.RecNo:=12;
Operations done: Request Rec#12 to MyClone + 9 records due of DBGrid2's
request. Nothing is fetched from Server-A. Everything is already in
tblMain's buffer.
Program:
MyClone1.Edit;
MyClone1.FieldByName('F1').AsString:='Foo';
MyClone1.Post;
Operations done: The field F1 of the Rec#14 is modified and the
modification is passed back to tblMain which will persist it to the
Server-A. Automagically (eg. using a visitor pattern) all the clones
which have Rec#14 will be aware of the modification.
(In fact, TClientDataSet acts in a similar manner but it lacks the
synchronization mechanism described here and buffers the records)
Program:
MyClone1.Filter:='F1="Foo"';
MyClone1.FilterEnabled:=True;
Operations done: The filter is passed to tblMain for processing and from
there only the records which match the criteria are requested. If these
records are already in tblMain's buffer so far so good. If not, then
these will be fetched from the Server-A. Beware here, we don't use the
tblMain.Filter property, but another engine which must be implemented
specifically for this job. Here we need an engine to support a different
'filter' for each clone (perhaps the filter to be stored as a list of
bookmarks).
About the indexes which you mentioned, TDataSet doesn't know nothing
about them so we don't know either. (TCloneDataSet hooks on a TDataSet).
What do you say?
--
m. th.
 

Re: What I would Like to See in Delphi

Captain Jake writes:
Quote
Find and replace of "string" with "ansistring" is "massive changes"?
"pchar" is an even bigger problem. Pchar will map to pWidechar in
Delphi 2008.
Which is OK as long as the Pchars are used, for example, in conjunction
with the WINAPI calls in windows.pas because Codegear will change
those declarations accordingly so the "wide" functions will be called.
So you can not just do a search/replace and change pchar into
pansichar because all Winapi calls will stop working then.
Leaving them as they are is dangerous also;
The real pain begins if you use "pchar" with third-party dll's that
continue to expect pchar=pansichar. And there are thousands,
maybe even millions of those. Many of them written in C.
Pchar is also commonly used to manipulate buffers, in which case
a "pansichar" behaviour is also desirable.
So, in the case of pchar, one will have to decide for each occurrence
if one wants a pansichar or a pwidechar. That may turn out to be
much more work than replacing string->ansistring in legacy code
because it is *these* pchars that cause GPF's/bluescreens.
--
Arthur Hoornweg
(In order to reply per e-mail, please just remove the ".net"
from my e-mail address. Leave the rest of the address intact
including the "antispam" part. I had to take this measure to
counteract unsollicited mail.)
 

Re: What I would Like to See in Delphi

"Arthur Hoornweg" <XXXX@XXXXX.COM>wrote
Quote
"pchar" is an even bigger problem.
Pchar will map to pWidechar in Delphi 2008.
Can we imagine the problems that today's kind of programmers
would have had with the shift from 16-bit integer to 32-integer that
occurred when we went from Delphi-1 to Delphi-2? --JohnH
 

Re: What I would Like to See in Delphi

Arthur Hoornweg <XXXX@XXXXX.COM>writes
<XXXX@XXXXX.COM>
Quote
So, in the case of pchar, one will have to decide for each occurrence
if one wants a pansichar or a pwidechar. That may turn out to be
much more work than replacing string->ansistring in legacy code
because it is *these* pchars that cause GPF's/bluescreens.
Good point.
The more I think about this, the more worried I get, especially when it comes
to all the third-party components I use.
--
***Free Your Mind***
Posted with JSNewsreader Preview 0.9.7.3757
 

Re: What I would Like to See in Delphi

"John Herbster" <herb-sci1_AT_sbcglobal.net>writes
Quote
Can we imagine the problems that today's kind of programmers
would have had with the shift from 16-bit integer to 32-integer that
occurred when we went from Delphi-1 to Delphi-2? --JohnH
I seem to recall that the shift to 32-bit did in fact render obsolete a fair
amount of code and require a rewrite of many an app. But that was part of
the overall shift to 32-bit, which had a certain historical inevitability
about it that made it palatable to the programming public. I don't see the
same inevitability about shifting to D2008. I fear this Unicode thing could
be a sales damper.
 

Re: What I would Like to See in Delphi

Captain Jake writes:
Quote
which had a certain historical inevitability about it that made it
palatable to the programming public. I don't see the same
inevitability about shifting to D2008.
There's certainly inevitability concerning Unicode, if one stays with
Windows.
--
Dave Nottage [TeamB]