[Persistence-sig] "Straw Baby" Persistence API

[Phillip J. Eby]

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.


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

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.