Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
P
persistent
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
Analytics
Analytics
Repository
Value Stream
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Commits
Issue Boards
Open sidebar
Kirill Smelkov
persistent
Commits
ad8303c6
Commit
ad8303c6
authored
Nov 21, 2018
by
Ramiro Batista da Luz
Committed by
Michael Howitz
Nov 21, 2018
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Fix some typos in docs. (#103)
parent
ed81c6f7
Changes
5
Hide whitespace changes
Inline
Side-by-side
Showing
5 changed files
with
15 additions
and
15 deletions
+15
-15
docs/api/attributes.rst
docs/api/attributes.rst
+2
-2
docs/api/cache.rst
docs/api/cache.rst
+4
-4
docs/api/pickling.rst
docs/api/pickling.rst
+1
-1
docs/glossary.rst
docs/glossary.rst
+1
-1
docs/using.rst
docs/using.rst
+7
-7
No files found.
docs/api/attributes.rst
View file @
ad8303c6
...
...
@@ -109,7 +109,7 @@ which activates the object:
>>> o._p_changed
False
It works for missing attribes too:
It works for missing attrib
ut
es too:
.. doctest::
...
...
@@ -182,7 +182,7 @@ We'll modify an attribute
>>> o.y
2
which reactivates it, and mark
e
s it as modified, because our
which reactivates it, and marks it as modified, because our
implementation marked it as modified:
.. doctest::
...
...
docs/api/cache.rst
View file @
ad8303c6
...
...
@@ -20,14 +20,14 @@ really provide the right interface given that:
The current cache implementation is intimately tied up with the
persistence implementation and has internal access to the persistence
state. The cache implementation can update the persistence state for
newly created and
i
ninitialized objects directly.
newly created and
u
ninitialized objects directly.
The future persistence and cache implementations will be far more
decoupled. The persistence implementation will only manage object
state and generate object-usage events. The cache implem
n
entation(s)
will be re
r
sponsible for managing persistence-related (meta-)state,
state and generate object-usage events. The cache implementation(s)
will be responsible for managing persistence-related (meta-)state,
such as _p_state, _p_changed, _p_oid, etc. So in that future
implemention, the cache will be more central to managing object
implement
at
ion, the cache will be more central to managing object
persistence information.
Caches have a :meth:`new_ghost` method that:
...
...
docs/api/pickling.rst
View file @
ad8303c6
...
...
@@ -82,7 +82,7 @@ ignores any slots which map onto the "persistent" namespace (prefixed with
>>> from persistent.tests.cucumbers import SubSlotted
>>> x = SubSlotted('x', 'y', 'z')
Note that we haven't yet assiged a value to the ``s4`` attribute:
Note that we haven't yet assig
n
ed a value to the ``s4`` attribute:
.. doctest::
...
...
docs/glossary.rst
View file @
ad8303c6
...
...
@@ -23,7 +23,7 @@ Glossary
that data to be loaded, which is referred to as :term:`activation`.
volatile attribute
Attributes of a persistent object which are *not* cap
u
tured as part
Attributes of a persistent object which are *not* captured as part
of its :term:`pickled data`. These attributes thus disappear during
:term:`deactivation` or :term:`invalidation`.
...
...
docs/using.rst
View file @
ad8303c6
...
...
@@ -7,7 +7,7 @@ Inheriting from :class:`persistent.Persistent`
==============================================
The basic mechanism for making your application's objects persistent
is mix-in in
t
eritance. Instances whose classes derive from
is mix-in in
h
eritance. Instances whose classes derive from
:class:`persistent.Persistent` are automatically capable of being
created as :term:`ghost` instances, being associated with a database
connection (called the :term:`jar`), and notifying the connection when
...
...
@@ -59,14 +59,14 @@ The examples below use a stub data manager class, and its stub cache class:
... ob.__setstate__({'x': 42})
.. note::
Notic that the ``DM`` class always sets the ``x`` attribute to the value
Notic
e
that the ``DM`` class always sets the ``x`` attribute to the value
``42`` when activating an object.
Persistent objects without a Data Manager
=========================================
Before
aersistent instance has been associt
ated with a a data manager (
Before
persistent instance has been associ
ated with a a data manager (
i.e., its ``_p_jar`` is still ``None``).
The examples below use a class, ``P``, defined as:
...
...
@@ -102,7 +102,7 @@ will always be ``False``.
>>> p._p_changed
False
The :attr:`_p_state` attribute is an integ
a
er, representing which of the
The :attr:`_p_state` attribute is an integer, representing which of the
"persistent lifecycle" states the object is in. Until the object is assigned
a :term:`jar`, this attribute will always be ``0`` (the ``UPTODATE``
constant):
...
...
@@ -437,9 +437,9 @@ Subclasses which override the attribute-management methods provided by
derived implementation must assume that the attribute value has been set by
the base class.
:meth:`__de
t
attr__`
When overriding ``__de
t
attr__``, the derived class implementation
**must** first call :meth:`persistent.IPersistent._p_de
t
attr`, passing the
:meth:`__de
l
attr__`
When overriding ``__de
l
attr__``, the derived class implementation
**must** first call :meth:`persistent.IPersistent._p_de
l
attr`, passing the
name being accessed. This method ensures that the object is
activated, if needed, and handles the "special" attributes which do not
require activation (``_p_*``). If ``_p_delattr`` returns ``True``, the
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment