Joao Morais wrote:
> Al Boldi wrote:
> >> A small overhead do exist actually,
> >
> > I don't think it's small, unless you mean small apps which deal with
> > textual data only. For large apps that deal with blobs, the overhead may
> > bring down your system.
>
> No, small overhead even to applications that handle large objects. There
> are three points to consider: 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.
Then comes the client-side, which we can control.
> 2. moving data between layers doesn't mean big
> overhead due to refcount of ansistrings or other managed objects;
Ok, that sounds like a cache manager. So you are not actually moving any
data, but rather managing the pointers.
Where is the data cached?
> 3.lazy loading of objects and attributes mixed with bulk retrieving.
And how does the app access this object-data?
> >> 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.
> > 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?
Thanks!
--
Al
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
