-
-
Notifications
You must be signed in to change notification settings - Fork 191
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
Avoid POSKeyError when commit occurs and we have savepoint that involves Plone Site #4026
Conversation
@wesleybl thanks for creating this Pull Request and helping to improve Plone! TL;DR: Finish pushing changes, pass all other checks, then paste a comment:
To ensure that these changes do not break other parts of Plone, the Plone test suite matrix needs to pass, but it takes 30-60 min. Other CI checks are usually much faster and the Plone Jenkins resources are limited, so when done pushing changes and all other checks pass either start all Jenkins PR jobs yourself, or simply add the comment above in this PR to start all the jobs automatically. Happy hacking! |
@jenkins-plone-org please run jobs |
Plone Site When ZODB handles savepoint and we have changes in Plone Site at that savepoint, it changes the `_p_estimated_size` attribute of Plone Site. This is an assignment to one of the special persistency attributes (identified by an _p_ name prefix); it should happen without access to any other attributes of obj. But obj._tree is accessed in __setattr__ of PloneSite class and results in a ZODB load which apparently fails. See: plone/plone.restapi#1823 (comment)
@d-maurer FYI |
@@ -61,7 +61,7 @@ def __getattr__(self, name): | |||
|
|||
def __setattr__(self, name, obj): | |||
# handle re setting an item as an attribute | |||
if self._tree is not None and name in self: | |||
if not name.startswith("_") and self._tree is not None and name in self: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't we be more strict with this change and check for name.startswith("_p_")
or name.startswith("_v_")
?
Alessandro Pisa wrote at 2024-10-14 22:28 -0700:
@ale-rt commented on this pull request.
> @@ -61,7 +61,7 @@ def __getattr__(self, name):
def __setattr__(self, name, obj):
# handle re setting an item as an attribute
- if self._tree is not None and name in self:
+ if not name.startswith("_") and self._tree is not None and name in self:
Shouldn't we be more strict with this change and check for `name.startswith("_p_") or `name.startswith("_v_")``?
Obviously, it depends on what is put into `_tree` in the first place.
When I looked at the `__setattr__` implementation, I got the impression
that the `_tree` is there to let the `PloneSite` emulate the behavior
of a "Large Folder", i.e. to accomodate a large number of content items.
In the "Large Folder" case, only content items are put into `_tree`,
"normal" attributes are stored directly on the object.
Should `PloneSite` do the same, then `startswith("_")` is sufficient
because the id of content items must not start with `_` (they would not
be publishable otherwise).
Should `PloneSite` store arbitrary attributes in `_tree`,
then `startswith("_p_")` might not be correct:
while all special persistency attributes have this name prefix,
the prefix can be used for other attributes as well and then
might be stored in `_tree` (event though it would not arrive there
via normal attribute assignment).
|
@jenkins-plone-org please run jobs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When ZODB handles savepoint and we have changes in Plone Site at that savepoint, it changes the
_p_estimated_size
attribute of Plone Site. This is an assignment to one of the special persistency attributes (identified by an_p_
name prefix); it should happen without access to any other attributes of obj. But obj._tree is accessed in__setattr__
of PloneSite class and results in a ZODB load which apparently fails.See: plone/plone.restapi#1823 (comment)