Guido van Rossum | 470be14 | 1995-03-17 16:07:09 +0000 | [diff] [blame] | 1 | \section{Standard Module \sectcode{shelve}} |
Guido van Rossum | e47da0a | 1997-07-17 16:34:52 +0000 | [diff] [blame^] | 2 | \label{module-shelve} |
Guido van Rossum | d188358 | 1995-02-15 15:53:08 +0000 | [diff] [blame] | 3 | \stmodindex{shelve} |
| 4 | \stmodindex{pickle} |
| 5 | \bimodindex{dbm} |
Guido van Rossum | 470be14 | 1995-03-17 16:07:09 +0000 | [diff] [blame] | 6 | \bimodindex{gdbm} |
Guido van Rossum | d188358 | 1995-02-15 15:53:08 +0000 | [diff] [blame] | 7 | |
| 8 | A ``shelf'' is a persistent, dictionary-like object. The difference |
| 9 | with ``dbm'' databases is that the values (not the keys!) in a shelf |
| 10 | can be essentially arbitrary Python objects --- anything that the |
| 11 | \code{pickle} module can handle. This includes most class instances, |
| 12 | recursive data types, and objects containing lots of shared |
| 13 | sub-objects. The keys are ordinary strings. |
| 14 | |
| 15 | To summarize the interface (\code{key} is a string, \code{data} is an |
| 16 | arbitrary object): |
| 17 | |
Guido van Rossum | e47da0a | 1997-07-17 16:34:52 +0000 | [diff] [blame^] | 18 | \bcode\begin{verbatim} |
Guido van Rossum | d188358 | 1995-02-15 15:53:08 +0000 | [diff] [blame] | 19 | import shelve |
| 20 | |
| 21 | d = shelve.open(filename) # open, with (g)dbm filename -- no suffix |
| 22 | |
| 23 | d[key] = data # store data at key (overwrites old data if |
| 24 | # using an existing key) |
| 25 | data = d[key] # retrieve data at key (raise KeyError if no |
| 26 | # such key) |
| 27 | del d[key] # delete data stored at key (raises KeyError |
| 28 | # if no such key) |
| 29 | flag = d.has_key(key) # true if the key exists |
| 30 | list = d.keys() # a list of all existing keys (slow!) |
| 31 | |
| 32 | d.close() # close it |
Guido van Rossum | e47da0a | 1997-07-17 16:34:52 +0000 | [diff] [blame^] | 33 | \end{verbatim}\ecode |
| 34 | % |
Guido van Rossum | 5680b95 | 1995-02-16 16:29:01 +0000 | [diff] [blame] | 35 | Restrictions: |
| 36 | |
| 37 | \begin{itemize} |
| 38 | |
| 39 | \item |
| 40 | The choice of which database package will be used (e.g. dbm or gdbm) |
| 41 | depends on which interface is available. Therefore it isn't safe to |
| 42 | open the database directly using dbm. The database is also |
| 43 | (unfortunately) subject to the limitations of dbm, if it is used --- |
| 44 | this means that (the pickled representation of) the objects stored in |
| 45 | the database should be fairly small, and in rare cases key collisions |
| 46 | may cause the database to refuse updates. |
| 47 | |
| 48 | \item |
Guido van Rossum | d188358 | 1995-02-15 15:53:08 +0000 | [diff] [blame] | 49 | Dependent on the implementation, closing a persistent dictionary may |
| 50 | or may not be necessary to flush changes to disk. |
| 51 | |
Guido van Rossum | 5680b95 | 1995-02-16 16:29:01 +0000 | [diff] [blame] | 52 | \item |
Guido van Rossum | 470be14 | 1995-03-17 16:07:09 +0000 | [diff] [blame] | 53 | The \code{shelve} module does not support {\em concurrent} read/write |
| 54 | access to shelved objects. (Multiple simultaneous read accesses are |
| 55 | safe.) When a program has a shelf open for writing, no other program |
| 56 | should have it open for reading or writing. \UNIX{} file locking can |
| 57 | be used to solve this, but this differs across \UNIX{} versions and |
| 58 | requires knowledge about the database implementation used. |
Guido van Rossum | 5680b95 | 1995-02-16 16:29:01 +0000 | [diff] [blame] | 59 | |
| 60 | \end{itemize} |