Writing persistent objects #22
Conversation
Still more work to do. Added machinery to make the documentation testable.
Still more work to do. Added machinery to make the documentation testable.
|
|
||
| Two of the main jobs of the ``Persistent`` base class is to detect | ||
| when an object has been accessed and when it has been modified. When | ||
| an object is accessed, it's state may need to be loaded from the |
| Special attributes | ||
| ================== | ||
|
|
||
| There are some attributes that are treated specially. |
There was a problem hiding this comment.
Is persistent documentation generated somewhere (e.g., readthedocs)? The IPersistent interface has a nice expanded discussion of these attributes that might be nice to link to if so. The discussion here and below pretty much covers it all, but I assume the IPersistent interface is canonical.
There was a problem hiding this comment.
http://persistent.readthedocs.io/en/latest/api/interfaces.html#persistent.interfaces.IPersistent ? It seems to be current.
There was a problem hiding this comment.
Weird, I wonder why I didn't see that.
The problem I have with those docs is that they're too low level and deal too much with internal aspects (e.g. stickiness).
I have no problem with linking to them though.
|
The text looks pretty good to me, other than the occasional minor typo or possibility to add a link. I didn't look at the build, but it passed, and I like the idea of tests! Here's why I think linking to zope.cachedesciptors, etc, might be a good idea: One of the good things about ZODB is that there are packages that can handle many different problems you might run into (e.g., |
| record from the book record and is managed by ZODB independent of the | ||
| management of the book. | ||
|
|
||
| In addition to ``PersistentList`` and ``PersistentMapping``, general |
There was a problem hiding this comment.
IDK, is it? I never used it myself.
There was a problem hiding this comment.
We used to use it, but even with it resolving conflicts, our (pretty high-volume write) use case turned out to be better served by Redis. But it works for what it does.
There was a problem hiding this comment.
I added a reference to it
|
I like the idea of including some links. I'll add some at the end of the topic. Please feel free to suggest/add more. Update: added |
|
Clear and concise. I have fixed a few minor typos on the branch. |
|
|
||
| If you modify a non-persistent mutable value of a persistent-object | ||
| attribute, you need to mark the persistent object as changed yourself | ||
| by setting ``_p_changed`` to True:: |
There was a problem hiding this comment.
In fact it is not set, but setting it to something triggers some functionality behind. If one reads _p_changed it does not return the value prior set. When I used this feature first several years ago I was kind of confused and only digging through the source helped me to understand what it is about. So I would phrase it:
If you modify a non-persistent mutable value of a persistent-object attribute,
you need to tell the persistent object that it has changed by assigning ``_p_changed`` a value.
The assignment marks the object as modified
(reading ``_p_changed`` does not tell you anything, since its just a trigger)::
There was a problem hiding this comment.
I don't understand this comment. You seem to be saying that reading _p_changed doesn't give an accurate result.
_p_changed is computed from and thus reflects the internal object state. Can you provide an example where reading _p_changed doesn't give the expected result?
…n/zodbdocs into writing-persistent-objects
|
This issue was moved to zopefoundation/ZODB#113 |
Plus: