| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
database, we need to use pickle instead of marshal. Pickle's more
reliable and portable anyway.
We can do auto-upgrade from marshal to pickle. If the .pck file isn't
found, we'll read the .db file. But we always write the .pck file and
if that's successful we can delete the .db file. We also do the
standard "write a .tmp file and rotate with os.rename()" dance.
|
| |
|
|
| |
memberships.
|
| |
|
|
|
| |
the valid Pending types. (They're 1-tuples so that the assert is more
robust).
|
| |
|
|
|
|
|
|
| |
the evictions dictionary too.
_save(): Go through and delete any evictions keys which don't appear
in the pending dictionary (i.e. we're cleaning up after ourselves
due to the above bug).
|
| | |
|
| |
|
|
|
|
| |
is a flag specifying whether pending entries should be removed from
the database or not, and will be used with the revamped confirmation
web ui.
|
| |
|
|
|
|
|
|
| |
Specifically,
CHANGE_OF_ADDRESS: new constant for this type of confirmable request.
new(): Add CHANGE_OF_ADDRESS to the assert.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Entry eviction times are stored as a sub-dictionary under a separate
key called `evictions'. This leaves the cookie data as whatever was
given to the new() function. The keys of the eviction dictionary
are the cookies and the values are the time at which the entry
should be removed.
- Another new key `version' for future backwards compatibility <wink>.
- Each entry for the cookie should have a op key as its first element,
which currently should be either Pending.SUBSCRIPTION or
Pending.UNSUBSCRIPTION.
new(): Make sure the `evictions' dictionary is present.
confirm(): Don't strip off the last element of the tuple.
_load(): If there's no pending.db file, return a dictionary containing
an empty `evictions' sub-dictionary.
_save(): Check the eviction times in the `evictions' sub-dictionary.
Also, add the schema `version' entry.
_update(): Fix the conversion from pending_subscriptions.db to
pending.db file format so that SUBSCRIPTION entries include a default
language. Also move the eviction times (which in the old format are
the time the request was made) to the `evictions' sub-dictionary and
add the PENDING_REQUEST_LIFE value.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
inside a class; use the module as if a singleton instance.
The pending database is now stored in data/pending.db.
new(): Stores a new cookie in the pending.db with the key an sha
hexdigest based on the current time, a random number and the content.
The timestamp is now the point in the future at which this entry can
be evicted.
confirm(): Given a cookie, return the data (with the timestamp
stripped off), or None if the cookie is missing from the database.
_load(), _save(): Rewritten and simplified low-level marshal/unmarshal
of the database. Assumes lock is acquired.
_update(): For use by the bin/update script to convert from
pending_subscription.db to pending.db (the old keys ought to be
compatible).
|
| | |
|
| |
|
|
| |
LockFile.AlreadyLockedError
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Eliminate an unlocked window, where another process could also load
the db, then save after the current process and stomp its changes.
All transactions are now atomically locked.
2. Implement periodic culling of the db, to remove old entries.
Otherwise (i assume) unclaimed entries would just accumulate
forever.
3. Simplified the interface so you can only put in new entries and
retrieve them. Cookie handling is implicit. All external
functionality is now all in two methods of the 'Pending' class object.
Details:
1. Atomicity: it used to be that the lock would only be set during the
write phase. Now, the db load and save handling is not exposed - it
is taken care of in the two exposed methods, which take care of the
locking around the load/save sequence.
Pending().new(stuff...) places an item's data in the db, returning its cookie.
Pending().confirmed(cookie) returns a tuple for the data, removing the item
from the db. It returns None if the cookie is not registered.
2. Periodically, on saves that occur longer than (module var)
CULL_INTERVAL after the last save, the db is checked for stale items,
and they're removed. Items are stale if they're older than the value
of the new default config var, PENDING_REQUEST_LIFE. (The timestamp
on the db is new, but old versions lacking it will just be culled on
the first save, and have it added.)
3. Two methods provide all the functionality:
Pending().new(stuff...) places an item in the db, returning a cookie
for it.
Pending().confirmed(cookie) returns the item, removing it from the
db - or it returns None if the item is not found.
|
| |
|
|
| |
try/finally, with unlocking being done in the finally clause.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
in pending...
|
| |
|