[Persistence-sig] A simple Observation API

[Sebastien Bigaret]

  Now that the code has shown up, I have some comments :) --just kidding, I
was just to busy to read the list since the beginning of the week, now I read
the whole stuuf ; I must admit I did not understand in details every single
arguments and points you discussed about, so I might have questions for some
stuff that were answered but that I didn't understand.

Here are some notes & questions I had while reading:

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. Of course, this should
  not defeat the 'smallest-possible-memory-footprint-requirement' pointed out
  in the sig charter ; 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.


+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, while 'changed' is for existing
(previously made persistent objects, is this right?

About RDBMS: I'm ok with what has been said ; I agree that most of the work
has to be done at DM-level ; observability, as shown in the demo. code, seems
sufficient for most purposes. The only thing I cannot see how it can be done
is:

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?


More on the Observation API:
> Note that this draft doesn't deal with any threading issues whatsoever.  

You asked earlier "does anybody have any *concrete* use cases where threaded
access to the *same* object is a necessity?". The only use-case I can think
about is when you have a pool of objects shared by all threads (e.g. to avoid
unnecessary round-trips to a DB for accessing mostly-read-only objects), where
it is possible that other objects, loaded/copied specifically for each thread,
can have references (relationships) to shared objects. I'm not saying,
however, that threading issues **should** be addressed because of this, i have
the feeling that, if you want such a feature, you can afford the extra effort
to make these shared objects thread-safe (e.g. reentrant locks are ok as long
as you access the objects' attributes using getters/setters and not directly).


> This is a fairly "transparent" API, although it still requires the user to 
> subclass a specific base, and declare which mutable attributes are touched 
> by what methods.  But it is less invasive, in that observation-specific 
> code does not need to be incorporated into the methods themselves.

It looks pretty to my eyes, indeed.

Last question to make sure I did not miss an important point: after having
read all your messages and after I had a look on the Persistence package in
Zope3, this is how I understand the ``unghostification'' of an object: it
holds a flag saying whether it is a ghost, and has a special attribute,
_p_datamanager.  The Persistent object has a _p_activate() method which in
turn calls the setstate() method an the IPersistentDataManager.setstate() ;
this is triggered automatically. Is that it?

  Can someone be more explicit about when this is triggered? I tried to look
at the C code but I'm not familiar at all with C code for python and couldnt
get a clear answer.


-- Sebastien.