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

Option to prevent storage of non-persistent mutable objects #94

Open
jimfulton opened this issue Sep 26, 2018 · 2 comments
Open

Option to prevent storage of non-persistent mutable objects #94

jimfulton opened this issue Sep 26, 2018 · 2 comments
Labels

Comments

@jimfulton
Copy link
Member

An important bit of ZODB fine print and, for some, a common pitfall is the persistence rule that if you store non-persistent subobjects, you need to take special case, possibly inviting bugs.

I think it would be useful to enforce a restriction to only storing persistent or immutable objects. Amongts the ways to do this:

  • White list known immutable objects, with a way to add objects to the white list. A possible way to whitelist custom objects might be to use an ABC. I suspect that a static white list would address 98% of cases. We might want to create some new immutable objects, like linked lists.

  • Inspect types for mutators (e.g. setattr, setitem). I can see this becomming a maintenance burden.

@jimfulton jimfulton added the idea label Sep 26, 2018
@pakal
Copy link

pakal commented May 1, 2019

I agree with this idea, non-persistence of objects (eg. imported from/to json and yaml) is a scary thing,

I developed lot of utilities to constantly check my DB (especially since some methods of Persistent* objects returned non-persistent types), but it remains dangerous. ---> https://github.com/ChrysalisTeam/pychronia/blob/7a9efef62da3451e1aa22efbe4c6ca0568dddf96/pychronia_game/utilities/__init__.py#L205

Having safeguards against this, built in ZODB, would be awesome.

@pakal
Copy link

pakal commented May 2, 2019

(See #112 for a nasty case where persistence can be lost unknowingly)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants