[ZODB-Dev] Re: Re: [Zope3-dev] Persistent module notes and proposal

Casey Duncan casey at zope.com
Thu Jan 8 13:55:43 EST 2004


On Thu, 08 Jan 2004 01:02:38 -0200
Leonardo Rochael Almeida <leo at hiper.com.br> wrote:

> At Mon, 05 Jan 2004 18:09:16 -0500, Jim Fulton wrote:
> 
> > Casey Duncan wrote:
> >> On Mon, 05 Jan 2004 16:36:24 -0500
> >> Jim Fulton <jim at zope.com> wrote:
> >> [...]
> >> 
> >>>If you wanted to share a list that way, you'd need to make it a
> >>>persistent list.
> >>>
> >>>I'm inclined to disallow import of non-persistent objects from
> >>>persistent modules.
> >> 
> >> 
> >> I agree. So classes and functions in persistent modules are
> >persistent> automagically?
> > 
> > Yes.  There's a mapping step that happens after module execution in
> > which we map regular classes, functions, and interfaces to
> > persistent ones, updating existing values as appropriate to make
> > imported refernces do the right thing.
> 
> What if we do it the other way around, and treat module globals as
> explicitly volatile?
> 
> PM globals wouldn't survive a server restart nor a PM edit, as editing
> the module would imply a module reload.

This is what I proposed previously. It won't work though because the
globals of persisten modules span multiple python processes. Unless
restarting one somehow invalidates the module globals in all other
processes. 

The only way to make that work as I understand it would be to make
persistent module globals local to the current process (i.e., not
themselves persistent). This is not the way it currently works (since
globals are subobjects of the module). I imagine the globals themselves
could be excluded from the state stored in the ZODB and each time the
module is loaded from the ZODB, it would be reconstructed from the
source state. Mutations to the global state would not be persisted, only
changes to the source state.

The downside to this as Jim pointed out is that then the global state
will not span multiple processes (except for the source state). This
matches what we expect for fs modules, but I think he has this feature
in mind for persistent ones (however this does contradict the notion
that the source expresses all of the state). Perhaps Jim can clarify the
use-cases for sharing global state across processes.
 
> I think this matches more closely the behaviour of fs modules, which
> we are already used to. This might make PMs less useful, but their
> semantic will be more easily defined and their implementation a little
> bit easier, I think. This achieves the goal of reflecting the module
> state solely by their source, and even allows PM global mutables to be
> used for volatile registries, just like fs modules.

Yes, that would help make things less surprising at first look.

-Casey




More information about the ZODB-Dev mailing list