Ticket #9529 (confirmed Bug)
Condition expression bug in Resource Registries on migrated instances
Reported by: | piv | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | 4.x |
Component: | Backend (Python) | Version: | 3.3 |
Keywords: | Cc: | piv |
Description
In case of migration of plone instance from 3.2 version (ResourceRegistries 1.4.3) to plone 3.3 version (ResourceRegistries 1.5.3) entries in resource registries (after very first cooking) starts to behave incorrectly.
The problem was indirectly introduced in this commit: [23701].
Here I'll try to explain why resources are cooked with bad (empty) cooked_expression on migrated plone instances.
Cooking process creates new resources by coping from original ones. And of course cooked_expression is not copied as it didn't exist previously, but copy method of resource class will set cooked_expression to expression with compiled empty string (starting point which causes the problem). Afterwards when condition expression is evaluated registry firstly looks if cooked_expression exists (for performance reasons) by calling getCookedExpression method:
def getCookedExpression(self): # Automatic inline migration of expressions if 'cooked_expression' not in self._data: expr = Expression(self._data['expression']) self._data['cooked_expression'] = expr return self._data['cooked_expression']
Here we can see that getCookedEpression will never re-set cooked_expression attribute. It only set it up in case this wasn't done before.
To workaround the issue I had to loop through the all registries resources and manually re-set expressions (using setExpression resource's method) and cook resources afterwards.
This problem could be resolved in two ways: 1. resorce's init method shouldn't set empty cooked_resource attribute, or 2. getCookedExpression method should look into cooked_expression and compare it's text with original expression, in case they aren't equal it'll re-compile cooked_expression.
Change History
comment:2 Changed 6 years ago by hannosch
- Owner hannosch deleted
I won't find the time or energy to look into this - un-assigning myself so it's clear someone else should tackle this.