Issue 241 in dexterity: dexterity through the web schema changes not propagating to other load balanced zope instances

[dext...@googlecode.com]

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 241 by a...@pretaweb.com: dexterity through the web schema
changes not propagating to other load balanced zope instances
http://code.google.com/p/dexterity/issues/detail?id=241

1) Run a Plone setup with dexterity installed of two or more instances
connecting to a ZEO

2) Add a new content type: Site Setup -> Content Dexterity Types -> Add New
Content Type...

The new content type does appear in the "Add New" menu when directly
connecting to each instance.

3) In one of the instances add a field to the new content type.

This field appears in the "Add New" form on this particular instances,
however, when adding or editing a object of this type in other instances
the field does not appear.

Restarting the other instances makes the change visible.

Version Overview
plone.app.dexterity 1.0.3
Plone 4.1.2 (4111)
CMF 2.2.4
Zope 2.13.10
Python 2.6.6 [GCC 4.5.2]

[dext...@googlecode.com]

Comment #1 on issue 241 by dgl...@gmail.com: dexterity through the web

schema changes not propagating to other load balanced zope instances
http://code.google.com/p/dexterity/issues/detail?id=241

Martin, I wonder if you could work on how to refactor the SchemaCache to
support this? It currently is local to a particular instance and makes no
effort to invalidate other instances' caches on an ISchemaInvalidatedEvent.

[dext...@googlecode.com]

Comment #2 on issue 241 by optil...@gmail.com: dexterity through the web

schema changes not propagating to other load balanced zope instances
http://code.google.com/p/dexterity/issues/detail?id=241

For personal reasons, I don't think I'll work on anything for a few
months. :) The cache is pretty simple, though, so it shouldn't be too hard
to do something about making it more clever. Maybe store in a _v_ variable
on the portal root object?

[dext...@googlecode.com]

Comment #3 on issue 241 by ale...@gmail.com: dexterity through the web

schema changes not propagating to other load balanced zope instances
http://code.google.com/p/dexterity/issues/detail?id=241

Looks like what's needed is to have the counter stored persistently on the
FTI or similar, rather than in the cache itself. You'd have to worry about
conflicts, but counter increments should only happen on schema changes,
which should be rare. The cache could either get an explicit context
passed in to help retrieve the counter value or just use the getSite hook
and hope for the best. Having a persistent "version number" associated
with schema changes might even have some use in other contexts.

A _v_ attribute without a similar persistent counter or reliable timestamp
somewhere would suffer the same problems (even worse since it would be a
per thread cache instead of per instance).

[dext...@googlecode.com]

Updates:
Status: Fixed

Comment #4 on issue 241 by dgl...@gmail.com: dexterity through the web

schema changes not propagating to other load balanced zope instances
http://code.google.com/p/dexterity/issues/detail?id=241

Just merged a pull request from Malthe Borch and Bo Simonson which fixes
this.