[Persistence-sig] "Straw Baby" Persistence API

[Ilia Iourovitski]

--- "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