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

[Casey Duncan]

On Mon, 05 Jan 2004 13:57:38 -0500
Jim Fulton <jim at zope.com> wrote:
[snip]
> >>The registry itself will be changing, although its name in the module 
> >>will not be rebound.
> > 
> > 
> > Hopefully if FooRegistry is itself a persistent object this would be ok? 
>  > This does not mutate the module at all.
> 
> The point is that it's module state that is not reflected by the module
> source.
> 
> If we synchronize the module to the file system, using only the module
> source, and then sync it back, the registry data will be lost.

Perhaps changes to persistent modules, like filesystem modules should not take effect until the application is restarted, or unless an explicit "refresh" operation is performed on the server. If that isn't the case then how do you deal with other modules that have imported from the persistent module?

Is the state of a persistent module itself persistend? If, for example, I stored a registry in a subobject of a persistent module, would its state persist across restarts?

If not, then the semantics are the same as filesystem modules. If you change a filesystem modules and reload it, global state is lost. In this case the problem is not so bad since it is the same as with filesystem modules.

If the state of a persistent module is itself persistent, then the problem is broader IMO since the semantics are considerably different from filesystem modules. On those grounds I would argue that persistence of module state would be a misfeature since it's  volatile in potentially surprising ways.
 
> > I agree with Tres that this rule should be strongly enforced.
>  > I am somewhat surprised that it would need to be a Zope-specific feature
>  > though.
>  >
>  > What makes it any more workable anywhere else?
> > Sounds like unecessary complication to create a Zope specific
>  > restriction when no-one has demanded anything different outside of Zope.
>  > I strongly suggest we should not prematurely generalize policies outside
>  > of Zope until some real users and use-cases show up demanding it.
> 
> It's largely driven by file-system synchronization.  Applications that
> don't use synchronization wouldn't need the restriction.

That sheds some more light, however the problem would still exist for TTW editing AFAICT.

-Casey