[Persistence-sig] A simple Observation API

[Jim Fulton]

Sebastien Bigaret wrote:

...

> About caching and caching policies: 
> 
>   Phillip did talk about 'transactional caching' and I'm not sure what it
>   really is, however, there is some needs to have 'application-wide' caching
>   mechanism to avoid unnecessary round-trips to the DB.

Right

 >   Of course, this should
>   not defeat the 'smallest-possible-memory-footprint-requirement' pointed out
>   in the sig charter ;

Where the goal is not "smallest possible" but small enough and smaller
than the entire database.

 >   but if an object has already been fetched somewhere
>   (and is still active in an other thread, or the cache/snapshots would have
>   been deleted), then it is usually unnecessary to re-fetch the object, simply
>   use the cached snapshot instead. But this sounds to me a bit off-topic for
>   this list.

One of the goals of ZODB's caching strategy is also to provide isolation between
separate threads. Different threads can have separate caches and so don't need
locks to mediate access to objects in the caches.

Concievably, an RDBMS-based data manager could employ a lower-level cache
to avoid duplicate RDBMS accesses among threads in much the way ZEO uses
a client cache to avoid extra trips to the storage server.


> 
> +1 on defining a state model for persistent objects ; however I'm a little
> fuzzy about the difference between 'unsaved' and 'changed'. To my
> understanding 'unsaved' is for new objects,

Right.

 > while 'changed' is for existing
> (previously made persistent objects, is this right?

Right.


...

> Ilia> create(object) storage shall populated id from rdbms
> Ilia> which is usually primary key.
> 
> Jim> This should not be necessary. One should be able to
> Jim> design a data manager that detected new objects and
> Jim> assigned them ids when referencing objects are created.
> 
> Can you elaborate on that?

Suppose I have a car object that has already been stored in
the database, but it doesn't have an engine.  I should be
able to say:

   # get the car ...

   car.engine = Engine()
   commit()

Now when I commit, the car's data manager should be able to notice that
it now has an engine and that the engine doesn't have an oid.
It will then know that an new engine object needs to be created and
that it's primary key (which is not necessarily the same as the oid)
needs to be stored in the cars engine column.)


Jim


-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (888) 344-4332            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org