Joao Morais wrote:
> Al Boldi wrote:
> > Joao Morais wrote:
> >> I am currently working in an IO-like project with a smarter, faster and
> >> more customizable OPF engine, decoupled frameworks (after all data type
> >> and opf aren't the same thing), no dbware or tdataset dependency, and
> >> the best item: no backward compatibility to bother.
> >> www.pressobjects.org
> >
> > Sounds great!
> >
> > Does your OPF handle data storage natively?
>
> The OPF just creates DDLs and DMLs based on an object oriented model,
> built over a data type framework. The DDLs and DMLs are sent to the
> database through a connection broker, built against Zeos, UIB, SQLdb
> (and also DOA and IBX when compiled with Delphi).
Oh.
> Native access is in the 2.0 roadmap.
That's great. You see, trying to create an OPF as a separate layer that
connects to the db via a broker is just broken by design, as this will
introduce a tremendous overhead due to the dual caching problem.
In fact, the correct way forward seems to be to implement the OPF as the
broker, just like you implement the broker against a specific db-lib. What
you get is a db specific OPF that wraps the broker inside it in a native
fashion.
Now, in the end this OPF may end up pluggable, but it would still be native
per db, with one single cache manager.
> Let me know if this answer your question.
Thanks!
--
Al
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
