Al Boldi wrote:
Joao Morais wrote:
1. the real bottleneck is in the database
and in the network;
Correct. Let's call this the server-side, which isn't under our control.
Sometimes it is, eg building smart DMLs and smart strategies to retrieve
data, using prepared statements when possible, and so on.
Then comes the client-side, which we can control.
Improvements in the client side sometimes doesn't worth the effort. If,
lets say, 90% of the time is in the server side and the network, a
perfect client side would increase 10% of the performance. The side
effect is the complexity to maintain and extend the code.
Other improvements that can be made regarding performance is creating
threads to perform some slow tasks in the background, while the
application answer some key or mouse events of the user.
Where is the data cached?
Attributes belong to business objects. BOs are reference counted and the
ones that wasn't removed from the memory are referenced by a cache that
belongs to the persistence service.
3.lazy loading of objects and attributes mixed with bulk retrieving.
And how does the app access this object-data?
Retrieving its OID through the persistence service. This service will
query the cache (binary tree -- todo list) in order to know if the
object was already instantiated. If it exist, its address is returned,
otherwise the persistence (xml, database, whatever) is queried in order
to retrieve information to instantiate such object.
and the way to remove it is writing a connection
broker that doesn't depend of a db suite like SQLdb or Zeos, and that
doesn't depend of the tdataset as well.
If you do it this way, then you are actually implementing proxies, and
proxies should not be used unless there is a need for them like for
border-gateways, because proxies add overhead.
I think you meant wrappers. And yes, wrappers to SQLdbs are necessary in
this case, because implement wrappers to database API at this stage of
the project demands an effort that I would like to use to other more
important tasks like tests, docs and the expert.
The problem with this is that, the proper construction of the OOrdb cache
manager is critically dependent on the native access to the dbAPI.
Otherwise you may be hindered by the dual-cache problem.
No, only one cache that references objects. No relational data is
cached, just some datasets.
What you may want to try is to refactor the OPF, dataBroker, and
dbConnectionLib into their respective layering components, and then
recompose a native OPF wrapper based on those layering components. This
should give a decoupled system while maintaining native performance.
Perhaps what you are proposing is something I have already implemented.
I don't use any db* class and have created an abstract data access to
improve speed as much as possible (or as I can) -- writing wrappers to
database APIs in future versions. Have a look in the code.
Sure. Can you give us a link to a tarball?
Sure. A 'zipball':
http://pressobjects.org/snapshot/press-snapshot-20071103-r706.zip or
subversion:
https://pressobjects.svn.sourceforge.net/svnroot/pressobjects/trunk
--
Joao Morais
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
