Skip to content
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

Small persistence related bug in atreal.filestorage.common #1

Open
tiazma opened this issue Apr 2, 2015 · 0 comments
Open

Small persistence related bug in atreal.filestorage.common #1

tiazma opened this issue Apr 2, 2015 · 0 comments

Comments

@tiazma
Copy link
Member

tiazma commented Apr 2, 2015

From Dieter Maurer::

A client has complained about a large increase in "FileStorage" size.
A quick analysis suggests that the "atreal.richfile.preview" previews
are responsible for this increase as previews are stored inside
the main ZODB not in blobs.

I have implemented a new "blobstore" (similar to "zodbstore") which
stores files in "BlobFile" rather than "ZodbFile". While developing
the corresponding migration script I hit the following bug:

  "atreal.filestorage.common.zodbstore.ZodbDir" derives from
  "OOBTree" but does not define its own "getstate/setstate".
  As a consequence, the content of its instances dicts is
 not persisted: after a "ZodbDir" is loaded from the ZODB,
 it no longer has attributes "name" and "parent".


In general: it is not without problems to inherit from a persistent
class with special C-level data structures (such as "OOBTree").
In order to get their private C-level data persisted, such a class must define
a special "getstate/setstate" which (usually) do not take an instance
dict into account. A derived class with instance dicts must provide
its own "getstate/setstate" implementation which ensures that both
the C-level structures of the base class as well as the instance dicts
are persisted.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant