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

Jim Fulton jim at zope.com
Mon Jan 5 14:35:43 EST 2004


Casey Duncan wrote:
> 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.

That would cause you to lose a significant benefit of persistent modules.
In any case, how would that help?


 > If that isn't the case then how do you deal with other modules that
 > have imported from the persistent module?

What do you mean? What's to take care of?

> Is the state of a persistent module itself persistend?

Yes.

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

Yes.

...

> 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.

Yes, except that here, you should realize that we have a sort of a persistent
application whos execution spans many physical process executions.

 > On those grounds I would argue that persistence of module state would be
 > a misfeature since it's  volatile in potentially surprising ways.

This doesn't make sense to me. In what sense if it volatile?

> 
>>>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.

True, if you edit the module, you reexecute it's source, and, depending on the
source, changes not reflected in the source would be lost.

All the more reason why I think that persistent modules should be limited to
containing only software (i.e. classes, functions, interfaces, and static
data).

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org





More information about the ZODB-Dev mailing list