You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: