-
Notifications
You must be signed in to change notification settings - Fork 71
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
4.4.1 Regression: Components._utilities
/_utility_registrations
can get out of sync with the cache
#93
Comments
jamadden
added a commit
that referenced
this issue
Jun 14, 2017
clrpackages
referenced
this issue
in clearlinux-pkgs/zope.interface
Jun 15, 2017
…rsion 4.4.2 4.4.2 (2017-06-14) ------------------ - Fix a regression storing ``zope.component.persistentregistry.PersistentRegistry`` instances. See `issue 85 <https://github.com/zopefoundation/zope.interface/issues/85>`_. - Fix a regression that could lead to the utility registration cache of ``Components`` getting out of sync. See `issue 93 <https://github.com/zopefoundation/zope.interface/issues/93>`_.
netbsd-srcmastr
referenced
this issue
in NetBSD/pkgsrc
Jun 19, 2017
4.4.2 (2017-06-14) ------------------ - Fix a regression storing ``zope.component.persistentregistry.PersistentRegistry`` instances. See `issue 85 <https://github.com/zopefoundation/zope.interface/issues/85>`_. - Fix a regression that could lead to the utility registration cache of ``Components`` getting out of sync. See `issue 93 <https://github.com/zopefoundation/zope.interface/issues/93>`_.
jsonn
referenced
this issue
in jsonn/pkgsrc
Jun 20, 2017
4.4.2 (2017-06-14) ------------------ - Fix a regression storing ``zope.component.persistentregistry.PersistentRegistry`` instances. See `issue 85 <https://github.com/zopefoundation/zope.interface/issues/85>`_. - Fix a regression that could lead to the utility registration cache of ``Components`` getting out of sync. See `issue 93 <https://github.com/zopefoundation/zope.interface/issues/93>`_.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The
_UtilityRegistrations
object makes a reference to theComponent
's_utilities
and_utility_registrations
when it is created. TheComponent
object holds a strong reference to the_UtilityRegistrations
. Presumably the_UtilityRegistrations
holds these two references to avoid holding a reference to theComponent
instance and thus introducing a cycle.The problem introduced in 4.4.1 is that if either of those two instance variables are assigned to, the cache object is not updated. Previously, accessing the cache would compare the identity of the objects it held with the identity of the objects the Component held and reset if they changed. Now that doesn't happen.
The use case is that subclasses may want to change the identity of
_utility_registrations
in theregisterUtility
method. Specifically, we have a subclass that will change the_utility_registrations
object to a BTree instead of a dict when it grows to a certain size.Now we could update our subclass to have a dependency on >= 4.4.1 and knowledge of the fact that the cache is now an instance attribute that also needs to be updated, but I'd prefer to see it handled here so that the cache is always consistent and guaranteed to be so.
The text was updated successfully, but these errors were encountered: