Joao Morais wrote: > Al Boldi wrote: > > 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.
Sounds great, really! > >> 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. Wow! > >>>> 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. Of course you are not caching any relational data, but you said that you are using a connection broker to the rdb, which caches the rdb data, which means extra overhead. > >>> 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 Ok, I had a quick look through the docs, and it seems that you have the design tightly coupled to the MVP. Is there a way to directly attach LCL objects to your OPF? Thanks! -- Al _________________________________________________________________ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
