[Persistence-sig] "Straw Baby" Persistence API
Ilia Iourovitski
iiourov@yahoo.com
Tue, 23 Jul 2002 11:35:48 -0700 (PDT)
--- "Phillip J. Eby" <pje@telecommunity.com> wrote:
> At 10:08 AM 7/23/02 -0700, Ilia Iourovitski wrote:
> >
> > > > load(object type, object id)->object
> > >
> > > An object type should be unnecessary. If a data
> > > manager
> > > needs to track this sort of information, it
> should
> > > embed it in the object id.
> >
> >In rdbms case id usually integer. adding the whole
> >package/class name can be expensive.
>
> This is easily addressed by using separate data
> managers for each table or
> other base class type. No need to carry the type in
> the object ID.
>
You mean one data manager per table. Too much.
>
> > > > query(string, parameters)->list of objects or
> > > smart
> > > > collection
> > > >
> > > > Those methods can be placed in
> > > > Persistence/IPersistentDataManager.py
> > >
> > > No, these methods are specific to particular
> data
> > > manager
> > > APIs, although I can imagine a number of data
> > > managers sharing an
> > > API like the one above. Note that
> > > IPersistentDataManager.py is
> > > an interface for use by persistent objects. It
> does
> > > not include
> > > all data-manager methods. Similarly,
> > > Transaction.IDataManager.IDataManager is the
> > > data-manager API
> > > used by the transaction framework.
> > >
> >And most storages like rdbms, ldap, xml has it.
>
> The most straightforward way to handle queries is by
> creating query data
> managers, which take OIDs that represent the
> parameters of the query.
>
Most of the time people retrive object by attributes.
not by OID.
> Note, by the way, that IPersistentDataManager is an
> interface exposed to
> persistent objects by their data manager. It is
> *not* the interface a data
> manager exposes to application code, which can and
> should be quite different.
>
>
> > > Data managers will implement
> > >
>
>Persistence.IPersistentDataManager.IPersistentDataManager
> > > and
> > > Transaction.IDataManager.IDataManager as well as
> > > application APIs
> > > like the one you propose above. Perhaps there
> should
> > > be some
> > > common data-manager application API somewhat
> like
> > > the one you propose
> > > above.
>
> I agree with Jim that none of this stuff is needed
> in the interface that a
> data manager exposes to persistent objects. This
> stuff would be in a data
> manager's application-level interface, and I don't
> see any need for
> standardization there; that's an area for value-add
> by competing
> persistence mechanisms and data manager
> implementations. Any
> standardization of them now would be
> counter-productive, I think.
>
It's already exist. Look at the JDO. In java land OR
Mappers popular because instead of learning every time
different api/query language you can use odmg/oql
against rdmbs, odbms, ldap, xml, you name it.
It is major selling point for "generic persistance"
toolkit.
__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com