[Zope-CMF] Re: [dev] RFC: Extensible propertysheet use cases

yuppie y.2004_ at wcm-solutions.de
Fri Oct 1 09:11:33 EDT 2004


Hi Michel!


Michel Pelletier wrote:
>>And what happens if getProperty detects a schema change? It's easy to 
>>change the schema in a way that's hard or even impossible to propagate
>>without data loss.
> 
> 
> No loss.  It works just like an instance whose Python class has
> changed.  

I guess we just have different audiences in mind. Modifying python 
classes after creating persistent instances is an advanced task. As 
Dieter pointed out, you usually need a migration script. Or you need 
code that migrates the properties 'on the fly'.

> If the instance has the property and the type doesn't (because it was
> presumably removed), return the instance's property.  If the type has
> the property and the instance doesn't, copy the type property's default
> value to the instance and return it.

And if the property type has changed?

> Again I'm a bit of a risk taker, so I might not be the best person to
> make this decision, but I don't see this change really modifying any of
> the underlying objects at all, types or their instances, because they
> all already come with the property sheets mechanism ready to go.
> 
> Additionally this will not break any existing usage of property sheets
> that I can think of, the only change WRT property sheets are the
> instanciation semantics, sheets get copied when object are created or
> accessed.  Existing objects and their pre-existing sheets are not
> affected.

I still believe a basic base class for TypeInfos would be useful. And I 
don't think the PropertySheets stuff is a basic feature that's useful in 
all kinds of TypeInfo classes.

Besides that, my sole concern is that the PropertySheets stuff is 
recognizable as an advanced feature. A new class would have resolved 
this, but that's not the only alternative.

> This just dawned on me, in fact this change does not require a new class
> or any modification to the exsiting class at all, it just requires
> replacing or providing an alternate 'invokeFactory'!  Call it
> 'invokeInstanceFactory'.  It does the sheet copying magic, creating
> copies of property sheets on the instance that subclass fixed schema and
> override getProperty to support schema changes.  No changes to the type
> class at all.

Can't see how this makes things simpler. invokeFactory is used in many 
places.


Cheers,
	Yuppie



More information about the Zope-CMF mailing list