-
-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
noLongerProvides seems broken -> ValueError #126
Comments
@jensens can u help? there are lots of changes u made in that 2.9.2 release |
plone.dexterity/plone/dexterity/content.py Line 162 in 24a5915
was not modified and so the __providedBy__ cache is not invalidated.
It looks like I am thinking about a solution, stay tuned. |
plone.dexterity 2.9.5 (same with 2.9.7) |
This is marked as blocker. Should this block a Plone 5.2.2 release? |
@mauritsvanrees if using plone.dexerity >= 2.9. |
maybe instancebehaviors are no more important? i see a big issue on the rise when we are forced to pin plone.dexterity to 2.9.1 when we are officially already at 2.9.7 this starts to itch in the backside of my head... @jensens i really need some reaction from your side, as you are - to me - the only one deep down into that topic. |
I would love to have this fixed, although I don't use instancebehaviors myself. Actually, I see Jens did a fix in collective/collective.instancebehavior@30d904d in February that seems related. It notifies The fix is not in a release yet. I see only @rnix can make a PyPI release. |
@mauritsvanrees i totally understand your motivation and would have done the same. the fix @30d9... did not do the trick sadly and it looks like a problem in plone.dexterity itself, not in instancebehavior. |
I will have a look the next days ... but I do not think this is a blocker. Instancebehaviors are a special case. |
thank you jens - rly looking forward for your help on that. i removed the blocker to not confuse/interfere with release plans and such. |
I'm using collective.instancebehavior 0.4 in plone.dexterity 2.10.0 (in Plone 5.2.3) and encountered this bug. It seems related to caching in zope.interface. In
The error is raised when After completing the request/transaction the interface is no longer provided by the object; when I call If zope.interface caching is indeed the culprit the cache should be purged before the |
@kcleong I can't reproduce that using just >>> from zope.interface import Interface, directlyProvides, directlyProvidedBy
>>> class IDirect(Interface):
... pass
...
>>> class Thing(object):
... pass
...
>>> thing = Thing()
>>> directlyProvides(thing, (IDirect,))
None
>>> IDirect.providedBy(thing)
True
>>> # Now manually mimic what `noLongerProvides` does so we can check the conditions
>>> directlyProvides(thing, directlyProvidedBy(thing) - IDirect)
None
>>> IDirect.providedBy(thing)
False |
I also do not think this is zope.interface related. Moreover it seems the SchemnaInvalidatedEvent https://github.com/collective/collective.instancebehavior/blob/30d904d44518f46828d3ad740a4ec6b8a4cf5540/src/collective/instancebehavior/__init__.py#L83 is not picked up correctly by plone.dexterity's schema cache. |
even this is in zope.interface.declarations.py
this error bumps up in collective.instancebehavior and also in simple behavior adapters.
plone.dexterity 2.9.1 does well; 2.9.2 breaks.
The text was updated successfully, but these errors were encountered: