[Persistence-sig] "Straw Baby" Persistence API

[Ilia Iourovitski]

--- "Phillip J. Eby" <pje@telecommunity.com> wrote:
> At 11:35 AM 7/23/02 -0700, Ilia Iourovitski wrote:
> 
> >--- "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.
> 
> Why?  I could simply do something like this:
> 
> class MyDBManager:
> 
>      def __init__(self, sqlconn):
>          self.table1 = TableDBManager("table1",
> sqlconn, ...)
>          self.table2 = TableDBManager("table2",
> sqlconn, ...)
>          ...
> 
> myDB = MyDBManager(someSQLconnection)
> 
> And then refer to myDB.table1['someKey'] to load an
> object.  This doesn't 
> seem like "too much", especially since you could
> generate the individual 
> DM's based on metadata.
> 
> At any rate, this is pretty much the approach I
> intend to use myself, 
> except that using PEAK eliminates the need for the
> __init__ method.
> 
> 
> 
> > > > > > 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.
> 
> Right.  So define a query manager that takes the
> attributes as fields in an 
> OID, and returns a persistent object that represents
> a sequence of 
> records.  e.g.
> 
> for object in someQueryMgr[
> ('param1value','param2value') ]:
>      ...
> 
> All you need is a separate query manager for each
> (parameterized) query 
> your app needs -- and again, there's nothting
> stopping you from generating 
> your own via metadata or even from OQL if that's
> your heart's desire.
> 
> 
> > > 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.
> 
> I'd have to disagree with you there.  There is very
> little commonality 
> between Java data mappers; many offer some sort of
> OQL dialect, but they 
> vary in so many other aspects of their
> implementations and usage that 
> calling them standardized would be a joke.
> 
Both Castor and Object Bridge support odmg and oql.
Object Bridge is going to be "db.apache.org standard".
JDO specification is close to odmg.

> Please note that specific persistence mechanisms and
> query languages -- 
> especially any kind of "generic persistence toolkit"
> -- are completely out 
> of scope for this SIG's goals.  We want to
> standardize the *basis* for you 
> to create your *own* persistence mechanisms, query
> languages, and so 
> on.  The SIG will not be creating any code that
> actually talks to any kind 
> of database, nor supplies any kind of data
> management API.  To the best of 
> my understanding, the SIG's charter is focused on
> these interfaces:
> 
> * The interface which objects to be persisted must
> supply to their data manager
> 
> * The interface which data managers must supply to
> their persistent objects
> 
> * The interface which transaction participants must
> supply to a transaction
> 
> * The interface which transaction objects supply to
> their participants
> 
> * The interface which transaction objects supply to
> an application
> 
> The items you are talking about are not a part of
> any of these interfaces.
> 





__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com