[Persistence-sig] "Straw Baby" Persistence API

[Ilia Iourovitski]

For RDBMS based storages api should
provides the following method:

create(object) storage shall populated id from rdbms
which is usually primary key.
delete(object) 
load(object type, object id)->object
query(string, parameters)->list of objects or smart
collection

Those methods can be placed in
Persistence/IPersistentDataManager.py

Thanks

Ilia



--- Jeremy Hylton <jeremy@zope.com> wrote:
> >>>>> "PJE" == Phillip J Eby <pje@telecommunity.com>
> writes:
> 
>   PJE> * Flag _p_changed *after* __setattr__, not
> before!  This will
>   PJE> help co-operative transaction participants
> play nicely
>   PJE> together, since they can't "write through" a
> change if they're
>   PJE> getting notified *before* the change takes
> place!  Docs should
>   PJE> also clarify that when set in other code,
> _p_changed should be
>   PJE> set at the latest possible moment, *after*
> the object is in its
>   PJE> new, stable state.
> 
> Can you flesh out this request?  The second sentence
> there suggests
> interesting issues, but doesn't spell them out.  
> 
> As for when _p_changed should be set: Why does it
> matter?
> 
>   PJE> * Keep the _p_atime slot, but don't fill it
> with anything by
>   PJE> default.
> 
> I'd just as soon drop it completely.  If a
> particular application
> wants to extend the base persistence interface, it
> can.
> 
>   PJE> * Get rid of the term "register", since
> objects won't
>   PJE> "register" with the transaction, and neither
> should they with
>   PJE> their data manager.  They should "inform
> their data manager"
>   PJE> that they have changed.  Something like an
> objectChanged()
>   PJE> message is appropriate in place of
> register().  I believe this
>   PJE> would clarify the API.
> 
> I don't have a problem with register().  In what way
> is the current
> interface unclear?
> 
>   PJE> By the way, my rationale for not taking any
> radical new
>   PJE> approaches to persistence, observation, or
> notification in this
>   PJE> proposal is that the existing Persistence
> package is
>   PJE> "transparent" enough, and has the benefit of
> lots of field
>   PJE> experience. 
> 
> I'd like to see some comments from people who
> haven't already used
> ZODB.  I worry that all the comments are coming from
> a small number of
> people who wrote or use ZODB's persistent mechanism,
> and that we'll
> make decisions will be limiting for other persistent
> applications.
> (But maybe there aren't any other such
> applications/users.)
> 
> Jeremy
> 
> 
> 
> _______________________________________________
> Persistence-sig mailing list
> Persistence-sig@python.org
>
http://mail.python.org/mailman-21/listinfo/persistence-sig


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