Commit | Line | Data |
---|---|---|
86530b38 AT |
1 | .\" Automatically generated by Pod::Man v1.34, Pod::Parser v1.13 |
2 | .\" | |
3 | .\" Standard preamble: | |
4 | .\" ======================================================================== | |
5 | .de Sh \" Subsection heading | |
6 | .br | |
7 | .if t .Sp | |
8 | .ne 5 | |
9 | .PP | |
10 | \fB\\$1\fR | |
11 | .PP | |
12 | .. | |
13 | .de Sp \" Vertical space (when we can't use .PP) | |
14 | .if t .sp .5v | |
15 | .if n .sp | |
16 | .. | |
17 | .de Vb \" Begin verbatim text | |
18 | .ft CW | |
19 | .nf | |
20 | .ne \\$1 | |
21 | .. | |
22 | .de Ve \" End verbatim text | |
23 | .ft R | |
24 | .fi | |
25 | .. | |
26 | .\" Set up some character translations and predefined strings. \*(-- will | |
27 | .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left | |
28 | .\" double quote, and \*(R" will give a right double quote. | will give a | |
29 | .\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used to | |
30 | .\" do unbreakable dashes and therefore won't be available. \*(C` and \*(C' | |
31 | .\" expand to `' in nroff, nothing in troff, for use with C<>. | |
32 | .tr \(*W-|\(bv\*(Tr | |
33 | .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' | |
34 | .ie n \{\ | |
35 | . ds -- \(*W- | |
36 | . ds PI pi | |
37 | . if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch | |
38 | . if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch | |
39 | . ds L" "" | |
40 | . ds R" "" | |
41 | . ds C` "" | |
42 | . ds C' "" | |
43 | 'br\} | |
44 | .el\{\ | |
45 | . ds -- \|\(em\| | |
46 | . ds PI \(*p | |
47 | . ds L" `` | |
48 | . ds R" '' | |
49 | 'br\} | |
50 | .\" | |
51 | .\" If the F register is turned on, we'll generate index entries on stderr for | |
52 | .\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index | |
53 | .\" entries marked with X<> in POD. Of course, you'll have to process the | |
54 | .\" output yourself in some meaningful fashion. | |
55 | .if \nF \{\ | |
56 | . de IX | |
57 | . tm Index:\\$1\t\\n%\t"\\$2" | |
58 | .. | |
59 | . nr % 0 | |
60 | . rr F | |
61 | .\} | |
62 | .\" | |
63 | .\" For nroff, turn off justification. Always turn off hyphenation; it makes | |
64 | .\" way too many mistakes in technical documents. | |
65 | .hy 0 | |
66 | .if n .na | |
67 | .\" | |
68 | .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2). | |
69 | .\" Fear. Run. Save yourself. No user-serviceable parts. | |
70 | . \" fudge factors for nroff and troff | |
71 | .if n \{\ | |
72 | . ds #H 0 | |
73 | . ds #V .8m | |
74 | . ds #F .3m | |
75 | . ds #[ \f1 | |
76 | . ds #] \fP | |
77 | .\} | |
78 | .if t \{\ | |
79 | . ds #H ((1u-(\\\\n(.fu%2u))*.13m) | |
80 | . ds #V .6m | |
81 | . ds #F 0 | |
82 | . ds #[ \& | |
83 | . ds #] \& | |
84 | .\} | |
85 | . \" simple accents for nroff and troff | |
86 | .if n \{\ | |
87 | . ds ' \& | |
88 | . ds ` \& | |
89 | . ds ^ \& | |
90 | . ds , \& | |
91 | . ds ~ ~ | |
92 | . ds / | |
93 | .\} | |
94 | .if t \{\ | |
95 | . ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u" | |
96 | . ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u' | |
97 | . ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u' | |
98 | . ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u' | |
99 | . ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u' | |
100 | . ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u' | |
101 | .\} | |
102 | . \" troff and (daisy-wheel) nroff accents | |
103 | .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V' | |
104 | .ds 8 \h'\*(#H'\(*b\h'-\*(#H' | |
105 | .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#] | |
106 | .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H' | |
107 | .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u' | |
108 | .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#] | |
109 | .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#] | |
110 | .ds ae a\h'-(\w'a'u*4/10)'e | |
111 | .ds Ae A\h'-(\w'A'u*4/10)'E | |
112 | . \" corrections for vroff | |
113 | .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u' | |
114 | .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u' | |
115 | . \" for low resolution devices (crt and lpr) | |
116 | .if \n(.H>23 .if \n(.V>19 \ | |
117 | \{\ | |
118 | . ds : e | |
119 | . ds 8 ss | |
120 | . ds o a | |
121 | . ds d- d\h'-1'\(ga | |
122 | . ds D- D\h'-1'\(hy | |
123 | . ds th \o'bp' | |
124 | . ds Th \o'LP' | |
125 | . ds ae ae | |
126 | . ds Ae AE | |
127 | .\} | |
128 | .rm #[ #] #H #V #F C | |
129 | .\" ======================================================================== | |
130 | .\" | |
131 | .IX Title "Storable 3" | |
132 | .TH Storable 3 "2002-06-01" "perl v5.8.0" "Perl Programmers Reference Guide" | |
133 | .SH "NAME" | |
134 | Storable \- persistence for Perl data structures | |
135 | .SH "SYNOPSIS" | |
136 | .IX Header "SYNOPSIS" | |
137 | .Vb 3 | |
138 | \& use Storable; | |
139 | \& store \e%table, 'file'; | |
140 | \& $hashref = retrieve('file'); | |
141 | .Ve | |
142 | .PP | |
143 | .Vb 1 | |
144 | \& use Storable qw(nstore store_fd nstore_fd freeze thaw dclone); | |
145 | .Ve | |
146 | .PP | |
147 | .Vb 3 | |
148 | \& # Network order | |
149 | \& nstore \e%table, 'file'; | |
150 | \& $hashref = retrieve('file'); # There is NO nretrieve() | |
151 | .Ve | |
152 | .PP | |
153 | .Vb 5 | |
154 | \& # Storing to and retrieving from an already opened file | |
155 | \& store_fd \e@array, \e*STDOUT; | |
156 | \& nstore_fd \e%table, \e*STDOUT; | |
157 | \& $aryref = fd_retrieve(\e*SOCKET); | |
158 | \& $hashref = fd_retrieve(\e*SOCKET); | |
159 | .Ve | |
160 | .PP | |
161 | .Vb 3 | |
162 | \& # Serializing to memory | |
163 | \& $serialized = freeze \e%table; | |
164 | \& %table_clone = %{ thaw($serialized) }; | |
165 | .Ve | |
166 | .PP | |
167 | .Vb 2 | |
168 | \& # Deep (recursive) cloning | |
169 | \& $cloneref = dclone($ref); | |
170 | .Ve | |
171 | .PP | |
172 | .Vb 5 | |
173 | \& # Advisory locking | |
174 | \& use Storable qw(lock_store lock_nstore lock_retrieve) | |
175 | \& lock_store \e%table, 'file'; | |
176 | \& lock_nstore \e%table, 'file'; | |
177 | \& $hashref = lock_retrieve('file'); | |
178 | .Ve | |
179 | .SH "DESCRIPTION" | |
180 | .IX Header "DESCRIPTION" | |
181 | The Storable package brings persistence to your Perl data structures | |
182 | containing \s-1SCALAR\s0, \s-1ARRAY\s0, \s-1HASH\s0 or \s-1REF\s0 objects, i.e. anything that can be | |
183 | conveniently stored to disk and retrieved at a later time. | |
184 | .PP | |
185 | It can be used in the regular procedural way by calling \f(CW\*(C`store\*(C'\fR with | |
186 | a reference to the object to be stored, along with the file name where | |
187 | the image should be written. | |
188 | .PP | |
189 | The routine returns \f(CW\*(C`undef\*(C'\fR for I/O problems or other internal error, | |
190 | a true value otherwise. Serious errors are propagated as a \f(CW\*(C`die\*(C'\fR exception. | |
191 | .PP | |
192 | To retrieve data stored to disk, use \f(CW\*(C`retrieve\*(C'\fR with a file name. | |
193 | The objects stored into that file are recreated into memory for you, | |
194 | and a \fIreference\fR to the root object is returned. In case an I/O error | |
195 | occurs while reading, \f(CW\*(C`undef\*(C'\fR is returned instead. Other serious | |
196 | errors are propagated via \f(CW\*(C`die\*(C'\fR. | |
197 | .PP | |
198 | Since storage is performed recursively, you might want to stuff references | |
199 | to objects that share a lot of common data into a single array or hash | |
200 | table, and then store that object. That way, when you retrieve back the | |
201 | whole thing, the objects will continue to share what they originally shared. | |
202 | .PP | |
203 | At the cost of a slight header overhead, you may store to an already | |
204 | opened file descriptor using the \f(CW\*(C`store_fd\*(C'\fR routine, and retrieve | |
205 | from a file via \f(CW\*(C`fd_retrieve\*(C'\fR. Those names aren't imported by default, | |
206 | so you will have to do that explicitly if you need those routines. | |
207 | The file descriptor you supply must be already opened, for read | |
208 | if you're going to retrieve and for write if you wish to store. | |
209 | .PP | |
210 | .Vb 2 | |
211 | \& store_fd(\e%table, *STDOUT) || die "can't store to stdout\en"; | |
212 | \& $hashref = fd_retrieve(*STDIN); | |
213 | .Ve | |
214 | .PP | |
215 | You can also store data in network order to allow easy sharing across | |
216 | multiple platforms, or when storing on a socket known to be remotely | |
217 | connected. The routines to call have an initial \f(CW\*(C`n\*(C'\fR prefix for \fInetwork\fR, | |
218 | as in \f(CW\*(C`nstore\*(C'\fR and \f(CW\*(C`nstore_fd\*(C'\fR. At retrieval time, your data will be | |
219 | correctly restored so you don't have to know whether you're restoring | |
220 | from native or network ordered data. Double values are stored stringified | |
221 | to ensure portability as well, at the slight risk of loosing some precision | |
222 | in the last decimals. | |
223 | .PP | |
224 | When using \f(CW\*(C`fd_retrieve\*(C'\fR, objects are retrieved in sequence, one | |
225 | object (i.e. one recursive tree) per associated \f(CW\*(C`store_fd\*(C'\fR. | |
226 | .PP | |
227 | If you're more from the object-oriented camp, you can inherit from | |
228 | Storable and directly store your objects by invoking \f(CW\*(C`store\*(C'\fR as | |
229 | a method. The fact that the root of the to-be-stored tree is a | |
230 | blessed reference (i.e. an object) is special-cased so that the | |
231 | retrieve does not provide a reference to that object but rather the | |
232 | blessed object reference itself. (Otherwise, you'd get a reference | |
233 | to that blessed object). | |
234 | .SH "MEMORY STORE" | |
235 | .IX Header "MEMORY STORE" | |
236 | The Storable engine can also store data into a Perl scalar instead, to | |
237 | later retrieve them. This is mainly used to freeze a complex structure in | |
238 | some safe compact memory place (where it can possibly be sent to another | |
239 | process via some \s-1IPC\s0, since freezing the structure also serializes it in | |
240 | effect). Later on, and maybe somewhere else, you can thaw the Perl scalar | |
241 | out and recreate the original complex structure in memory. | |
242 | .PP | |
243 | Surprisingly, the routines to be called are named \f(CW\*(C`freeze\*(C'\fR and \f(CW\*(C`thaw\*(C'\fR. | |
244 | If you wish to send out the frozen scalar to another machine, use | |
245 | \&\f(CW\*(C`nfreeze\*(C'\fR instead to get a portable image. | |
246 | .PP | |
247 | Note that freezing an object structure and immediately thawing it | |
248 | actually achieves a deep cloning of that structure: | |
249 | .PP | |
250 | .Vb 1 | |
251 | \& dclone(.) = thaw(freeze(.)) | |
252 | .Ve | |
253 | .PP | |
254 | Storable provides you with a \f(CW\*(C`dclone\*(C'\fR interface which does not create | |
255 | that intermediary scalar but instead freezes the structure in some | |
256 | internal memory space and then immediately thaws it out. | |
257 | .SH "ADVISORY LOCKING" | |
258 | .IX Header "ADVISORY LOCKING" | |
259 | The \f(CW\*(C`lock_store\*(C'\fR and \f(CW\*(C`lock_nstore\*(C'\fR routine are equivalent to | |
260 | \&\f(CW\*(C`store\*(C'\fR and \f(CW\*(C`nstore\*(C'\fR, except that they get an exclusive lock on | |
261 | the file before writing. Likewise, \f(CW\*(C`lock_retrieve\*(C'\fR does the same | |
262 | as \f(CW\*(C`retrieve\*(C'\fR, but also gets a shared lock on the file before reading. | |
263 | .PP | |
264 | As with any advisory locking scheme, the protection only works if you | |
265 | systematically use \f(CW\*(C`lock_store\*(C'\fR and \f(CW\*(C`lock_retrieve\*(C'\fR. If one side of | |
266 | your application uses \f(CW\*(C`store\*(C'\fR whilst the other uses \f(CW\*(C`lock_retrieve\*(C'\fR, | |
267 | you will get no protection at all. | |
268 | .PP | |
269 | The internal advisory locking is implemented using Perl's \fIflock()\fR | |
270 | routine. If your system does not support any form of \fIflock()\fR, or if | |
271 | you share your files across \s-1NFS\s0, you might wish to use other forms | |
272 | of locking by using modules such as LockFile::Simple which lock a | |
273 | file using a filesystem entry, instead of locking the file descriptor. | |
274 | .SH "SPEED" | |
275 | .IX Header "SPEED" | |
276 | The heart of Storable is written in C for decent speed. Extra low-level | |
277 | optimizations have been made when manipulating perl internals, to | |
278 | sacrifice encapsulation for the benefit of greater speed. | |
279 | .SH "CANONICAL REPRESENTATION" | |
280 | .IX Header "CANONICAL REPRESENTATION" | |
281 | Normally, Storable stores elements of hashes in the order they are | |
282 | stored internally by Perl, i.e. pseudo\-randomly. If you set | |
283 | \&\f(CW$Storable::canonical\fR to some \f(CW\*(C`TRUE\*(C'\fR value, Storable will store | |
284 | hashes with the elements sorted by their key. This allows you to | |
285 | compare data structures by comparing their frozen representations (or | |
286 | even the compressed frozen representations), which can be useful for | |
287 | creating lookup tables for complicated queries. | |
288 | .PP | |
289 | Canonical order does not imply network order; those are two orthogonal | |
290 | settings. | |
291 | .SH "FORWARD COMPATIBILITY" | |
292 | .IX Header "FORWARD COMPATIBILITY" | |
293 | This release of Storable can be used on a newer version of Perl to | |
294 | serialize data which is not supported by earlier Perls. By default, | |
295 | Storable will attempt to do the right thing, by \f(CW\*(C`croak()\*(C'\fRing if it | |
296 | encounters data that it cannot deserialize. However, the defaults | |
297 | can be changed as follows: | |
298 | .IP "utf8 data" 4 | |
299 | .IX Item "utf8 data" | |
300 | Perl 5.6 added support for Unicode characters with code points > 255, | |
301 | and Perl 5.8 has full support for Unicode characters in hash keys. | |
302 | Perl internally encodes strings with these characters using utf8, and | |
303 | Storable serializes them as utf8. By default, if an older version of | |
304 | Perl encounters a utf8 value it cannot represent, it will \f(CW\*(C`croak()\*(C'\fR. | |
305 | To change this behaviour so that Storable deserializes utf8 encoded | |
306 | values as the string of bytes (effectively dropping the \fIis_utf8\fR flag) | |
307 | set \f(CW$Storable::drop_utf8\fR to some \f(CW\*(C`TRUE\*(C'\fR value. This is a form of | |
308 | data loss, because with \f(CW$drop_utf8\fR true, it becomes impossible to tell | |
309 | whether the original data was the Unicode string, or a series of bytes | |
310 | that happen to be valid utf8. | |
311 | .IP "restricted hashes" 4 | |
312 | .IX Item "restricted hashes" | |
313 | Perl 5.8 adds support for restricted hashes, which have keys | |
314 | restricted to a given set, and can have values locked to be read only. | |
315 | By default, when Storable encounters a restricted hash on a perl | |
316 | that doesn't support them, it will deserialize it as a normal hash, | |
317 | silently discarding any placeholder keys and leaving the keys and | |
318 | all values unlocked. To make Storable \f(CW\*(C`croak()\*(C'\fR instead, set | |
319 | \&\f(CW$Storable::downgrade_restricted\fR to a \f(CW\*(C`FALSE\*(C'\fR value. To restore | |
320 | the default set it back to some \f(CW\*(C`TRUE\*(C'\fR value. | |
321 | .IP "files from future versions of Storable" 4 | |
322 | .IX Item "files from future versions of Storable" | |
323 | Earlier versions of Storable would immediately croak if they encountered | |
324 | a file with a higher internal version number than the reading Storable | |
325 | knew about. Internal version numbers are increased each time new data | |
326 | types (such as restricted hashes) are added to the vocabulary of the file | |
327 | format. This meant that a newer Storable module had no way of writing a | |
328 | file readable by an older Storable, even if the writer didn't store newer | |
329 | data types. | |
330 | .Sp | |
331 | This version of Storable will defer croaking until it encounters a data | |
332 | type in the file that it does not recognize. This means that it will | |
333 | continue to read files generated by newer Storable modules which are careful | |
334 | in what they write out, making it easier to upgrade Storable modules in a | |
335 | mixed environment. | |
336 | .Sp | |
337 | The old behaviour of immediate croaking can be re-instated by setting | |
338 | \&\f(CW$Storable::accept_future_minor\fR to some \f(CW\*(C`FALSE\*(C'\fR value. | |
339 | .PP | |
340 | All these variables have no effect on a newer Perl which supports the | |
341 | relevant feature. | |
342 | .SH "ERROR REPORTING" | |
343 | .IX Header "ERROR REPORTING" | |
344 | Storable uses the \*(L"exception\*(R" paradigm, in that it does not try to workaround | |
345 | failures: if something bad happens, an exception is generated from the | |
346 | caller's perspective (see Carp and \f(CW\*(C`croak()\*(C'\fR). Use eval {} to trap | |
347 | those exceptions. | |
348 | .PP | |
349 | When Storable croaks, it tries to report the error via the \f(CW\*(C`logcroak()\*(C'\fR | |
350 | routine from the \f(CW\*(C`Log::Agent\*(C'\fR package, if it is available. | |
351 | .PP | |
352 | Normal errors are reported by having \fIstore()\fR or \fIretrieve()\fR return \f(CW\*(C`undef\*(C'\fR. | |
353 | Such errors are usually I/O errors (or truncated stream errors at retrieval). | |
354 | .SH "WIZARDS ONLY" | |
355 | .IX Header "WIZARDS ONLY" | |
356 | .Sh "Hooks" | |
357 | .IX Subsection "Hooks" | |
358 | Any class may define hooks that will be called during the serialization | |
359 | and deserialization process on objects that are instances of that class. | |
360 | Those hooks can redefine the way serialization is performed (and therefore, | |
361 | how the symmetrical deserialization should be conducted). | |
362 | .PP | |
363 | Since we said earlier: | |
364 | .PP | |
365 | .Vb 1 | |
366 | \& dclone(.) = thaw(freeze(.)) | |
367 | .Ve | |
368 | .PP | |
369 | everything we say about hooks should also hold for deep cloning. However, | |
370 | hooks get to know whether the operation is a mere serialization, or a cloning. | |
371 | .PP | |
372 | Therefore, when serializing hooks are involved, | |
373 | .PP | |
374 | .Vb 1 | |
375 | \& dclone(.) <> thaw(freeze(.)) | |
376 | .Ve | |
377 | .PP | |
378 | Well, you could keep them in sync, but there's no guarantee it will always | |
379 | hold on classes somebody else wrote. Besides, there is little to gain in | |
380 | doing so: a serializing hook could keep only one attribute of an object, | |
381 | which is probably not what should happen during a deep cloning of that | |
382 | same object. | |
383 | .PP | |
384 | Here is the hooking interface: | |
385 | .ie n .IP """STORABLE_freeze""\fR \fIobj\fR, \fIcloning" 4 | |
386 | .el .IP "\f(CWSTORABLE_freeze\fR \fIobj\fR, \fIcloning\fR" 4 | |
387 | .IX Item "STORABLE_freeze obj, cloning" | |
388 | The serializing hook, called on the object during serialization. It can be | |
389 | inherited, or defined in the class itself, like any other method. | |
390 | .Sp | |
391 | Arguments: \fIobj\fR is the object to serialize, \fIcloning\fR is a flag indicating | |
392 | whether we're in a \fIdclone()\fR or a regular serialization via \fIstore()\fR or \fIfreeze()\fR. | |
393 | .Sp | |
394 | Returned value: A \s-1LIST\s0 \f(CW\*(C`($serialized, $ref1, $ref2, ...)\*(C'\fR where \f(CW$serialized\fR | |
395 | is the serialized form to be used, and the optional \f(CW$ref1\fR, \f(CW$ref2\fR, etc... are | |
396 | extra references that you wish to let the Storable engine serialize. | |
397 | .Sp | |
398 | At deserialization time, you will be given back the same \s-1LIST\s0, but all the | |
399 | extra references will be pointing into the deserialized structure. | |
400 | .Sp | |
401 | The \fBfirst time\fR the hook is hit in a serialization flow, you may have it | |
402 | return an empty list. That will signal the Storable engine to further | |
403 | discard that hook for this class and to therefore revert to the default | |
404 | serialization of the underlying Perl data. The hook will again be normally | |
405 | processed in the next serialization. | |
406 | .Sp | |
407 | Unless you know better, serializing hook should always say: | |
408 | .Sp | |
409 | .Vb 5 | |
410 | \& sub STORABLE_freeze { | |
411 | \& my ($self, $cloning) = @_; | |
412 | \& return if $cloning; # Regular default serialization | |
413 | \& .... | |
414 | \& } | |
415 | .Ve | |
416 | .Sp | |
417 | in order to keep reasonable \fIdclone()\fR semantics. | |
418 | .ie n .IP """STORABLE_thaw""\fR \fIobj\fR, \fIcloning\fR, \fIserialized, ..." 4 | |
419 | .el .IP "\f(CWSTORABLE_thaw\fR \fIobj\fR, \fIcloning\fR, \fIserialized\fR, ..." 4 | |
420 | .IX Item "STORABLE_thaw obj, cloning, serialized, ..." | |
421 | The deserializing hook called on the object during deserialization. | |
422 | But wait: if we're deserializing, there's no object yet... right? | |
423 | .Sp | |
424 | Wrong: the Storable engine creates an empty one for you. If you know Eiffel, | |
425 | you can view \f(CW\*(C`STORABLE_thaw\*(C'\fR as an alternate creation routine. | |
426 | .Sp | |
427 | This means the hook can be inherited like any other method, and that | |
428 | \&\fIobj\fR is your blessed reference for this particular instance. | |
429 | .Sp | |
430 | The other arguments should look familiar if you know \f(CW\*(C`STORABLE_freeze\*(C'\fR: | |
431 | \&\fIcloning\fR is true when we're part of a deep clone operation, \fIserialized\fR | |
432 | is the serialized string you returned to the engine in \f(CW\*(C`STORABLE_freeze\*(C'\fR, | |
433 | and there may be an optional list of references, in the same order you gave | |
434 | them at serialization time, pointing to the deserialized objects (which | |
435 | have been processed courtesy of the Storable engine). | |
436 | .Sp | |
437 | When the Storable engine does not find any \f(CW\*(C`STORABLE_thaw\*(C'\fR hook routine, | |
438 | it tries to load the class by requiring the package dynamically (using | |
439 | the blessed package name), and then re-attempts the lookup. If at that | |
440 | time the hook cannot be located, the engine croaks. Note that this mechanism | |
441 | will fail if you define several classes in the same file, but perlmod | |
442 | warned you. | |
443 | .Sp | |
444 | It is up to you to use this information to populate \fIobj\fR the way you want. | |
445 | .Sp | |
446 | Returned value: none. | |
447 | .Sh "Predicates" | |
448 | .IX Subsection "Predicates" | |
449 | Predicates are not exportable. They must be called by explicitly prefixing | |
450 | them with the Storable package name. | |
451 | .ie n .IP """Storable::last_op_in_netorder""" 4 | |
452 | .el .IP "\f(CWStorable::last_op_in_netorder\fR" 4 | |
453 | .IX Item "Storable::last_op_in_netorder" | |
454 | The \f(CW\*(C`Storable::last_op_in_netorder()\*(C'\fR predicate will tell you whether | |
455 | network order was used in the last store or retrieve operation. If you | |
456 | don't know how to use this, just forget about it. | |
457 | .ie n .IP """Storable::is_storing""" 4 | |
458 | .el .IP "\f(CWStorable::is_storing\fR" 4 | |
459 | .IX Item "Storable::is_storing" | |
460 | Returns true if within a store operation (via STORABLE_freeze hook). | |
461 | .ie n .IP """Storable::is_retrieving""" 4 | |
462 | .el .IP "\f(CWStorable::is_retrieving\fR" 4 | |
463 | .IX Item "Storable::is_retrieving" | |
464 | Returns true if within a retrieve operation (via STORABLE_thaw hook). | |
465 | .Sh "Recursion" | |
466 | .IX Subsection "Recursion" | |
467 | With hooks comes the ability to recurse back to the Storable engine. | |
468 | Indeed, hooks are regular Perl code, and Storable is convenient when | |
469 | it comes to serializing and deserializing things, so why not use it | |
470 | to handle the serialization string? | |
471 | .PP | |
472 | There are a few things you need to know, however: | |
473 | .IP "\(bu" 4 | |
474 | You can create endless loops if the things you serialize via \fIfreeze()\fR | |
475 | (for instance) point back to the object we're trying to serialize in | |
476 | the hook. | |
477 | .IP "\(bu" 4 | |
478 | Shared references among objects will not stay shared: if we're serializing | |
479 | the list of object [A, C] where both object A and C refer to the \s-1SAME\s0 object | |
480 | B, and if there is a serializing hook in A that says freeze(B), then when | |
481 | deserializing, we'll get [A', C'] where A' refers to B', but C' refers to D, | |
482 | a deep clone of B'. The topology was not preserved. | |
483 | .PP | |
484 | That's why \f(CW\*(C`STORABLE_freeze\*(C'\fR lets you provide a list of references | |
485 | to serialize. The engine guarantees that those will be serialized in the | |
486 | same context as the other objects, and therefore that shared objects will | |
487 | stay shared. | |
488 | .PP | |
489 | In the above [A, C] example, the \f(CW\*(C`STORABLE_freeze\*(C'\fR hook could return: | |
490 | .PP | |
491 | .Vb 1 | |
492 | \& ("something", $self->{B}) | |
493 | .Ve | |
494 | .PP | |
495 | and the B part would be serialized by the engine. In \f(CW\*(C`STORABLE_thaw\*(C'\fR, you | |
496 | would get back the reference to the B' object, deserialized for you. | |
497 | .PP | |
498 | Therefore, recursion should normally be avoided, but is nonetheless supported. | |
499 | .Sh "Deep Cloning" | |
500 | .IX Subsection "Deep Cloning" | |
501 | There is a Clone module available on \s-1CPAN\s0 which implements deep cloning | |
502 | natively, i.e. without freezing to memory and thawing the result. It is | |
503 | aimed to replace Storable's \fIdclone()\fR some day. However, it does not currently | |
504 | support Storable hooks to redefine the way deep cloning is performed. | |
505 | .SH "Storable magic" | |
506 | .IX Header "Storable magic" | |
507 | Yes, there's a lot of that :\-) But more precisely, in \s-1UNIX\s0 systems | |
508 | there's a utility called \f(CW\*(C`file\*(C'\fR, which recognizes data files based on | |
509 | their contents (usually their first few bytes). For this to work, | |
510 | a certain file called \fImagic\fR needs to taught about the \fIsignature\fR | |
511 | of the data. Where that configuration file lives depends on the \s-1UNIX\s0 | |
512 | flavour; often it's something like \fI/usr/share/misc/magic\fR or | |
513 | \&\fI/etc/magic\fR. Your system administrator needs to do the updating of | |
514 | the \fImagic\fR file. The necessary signature information is output to | |
515 | \&\s-1STDOUT\s0 by invoking \fIStorable::show_file_magic()\fR. Note that the \s-1GNU\s0 | |
516 | implementation of the \f(CW\*(C`file\*(C'\fR utility, version 3.38 or later, | |
517 | is expected to contain support for recognising Storable files | |
518 | out\-of\-the\-box, in addition to other kinds of Perl files. | |
519 | .SH "EXAMPLES" | |
520 | .IX Header "EXAMPLES" | |
521 | Here are some code samples showing a possible usage of Storable: | |
522 | .PP | |
523 | .Vb 1 | |
524 | \& use Storable qw(store retrieve freeze thaw dclone); | |
525 | .Ve | |
526 | .PP | |
527 | .Vb 1 | |
528 | \& %color = ('Blue' => 0.1, 'Red' => 0.8, 'Black' => 0, 'White' => 1); | |
529 | .Ve | |
530 | .PP | |
531 | .Vb 1 | |
532 | \& store(\e%color, '/tmp/colors') or die "Can't store %a in /tmp/colors!\en"; | |
533 | .Ve | |
534 | .PP | |
535 | .Vb 3 | |
536 | \& $colref = retrieve('/tmp/colors'); | |
537 | \& die "Unable to retrieve from /tmp/colors!\en" unless defined $colref; | |
538 | \& printf "Blue is still %lf\en", $colref->{'Blue'}; | |
539 | .Ve | |
540 | .PP | |
541 | .Vb 1 | |
542 | \& $colref2 = dclone(\e%color); | |
543 | .Ve | |
544 | .PP | |
545 | .Vb 3 | |
546 | \& $str = freeze(\e%color); | |
547 | \& printf "Serialization of %%color is %d bytes long.\en", length($str); | |
548 | \& $colref3 = thaw($str); | |
549 | .Ve | |
550 | .PP | |
551 | which prints (on my machine): | |
552 | .PP | |
553 | .Vb 2 | |
554 | \& Blue is still 0.100000 | |
555 | \& Serialization of %color is 102 bytes long. | |
556 | .Ve | |
557 | .SH "WARNING" | |
558 | .IX Header "WARNING" | |
559 | If you're using references as keys within your hash tables, you're bound | |
560 | to be disappointed when retrieving your data. Indeed, Perl stringifies | |
561 | references used as hash table keys. If you later wish to access the | |
562 | items via another reference stringification (i.e. using the same | |
563 | reference that was used for the key originally to record the value into | |
564 | the hash table), it will work because both references stringify to the | |
565 | same string. | |
566 | .PP | |
567 | It won't work across a sequence of \f(CW\*(C`store\*(C'\fR and \f(CW\*(C`retrieve\*(C'\fR operations, | |
568 | however, because the addresses in the retrieved objects, which are | |
569 | part of the stringified references, will probably differ from the | |
570 | original addresses. The topology of your structure is preserved, | |
571 | but not hidden semantics like those. | |
572 | .PP | |
573 | On platforms where it matters, be sure to call \f(CW\*(C`binmode()\*(C'\fR on the | |
574 | descriptors that you pass to Storable functions. | |
575 | .PP | |
576 | Storing data canonically that contains large hashes can be | |
577 | significantly slower than storing the same data normally, as | |
578 | temporary arrays to hold the keys for each hash have to be allocated, | |
579 | populated, sorted and freed. Some tests have shown a halving of the | |
580 | speed of storing \*(-- the exact penalty will depend on the complexity of | |
581 | your data. There is no slowdown on retrieval. | |
582 | .SH "BUGS" | |
583 | .IX Header "BUGS" | |
584 | You can't store \s-1GLOB\s0, \s-1CODE\s0, \s-1FORMLINE\s0, etc.... If you can define | |
585 | semantics for those operations, feel free to enhance Storable so that | |
586 | it can deal with them. | |
587 | .PP | |
588 | The store functions will \f(CW\*(C`croak\*(C'\fR if they run into such references | |
589 | unless you set \f(CW$Storable::forgive_me\fR to some \f(CW\*(C`TRUE\*(C'\fR value. In that | |
590 | case, the fatal message is turned in a warning and some | |
591 | meaningless string is stored instead. | |
592 | .PP | |
593 | Setting \f(CW$Storable::canonical\fR may not yield frozen strings that | |
594 | compare equal due to possible stringification of numbers. When the | |
595 | string version of a scalar exists, it is the form stored; therefore, | |
596 | if you happen to use your numbers as strings between two freezing | |
597 | operations on the same data structures, you will get different | |
598 | results. | |
599 | .PP | |
600 | When storing doubles in network order, their value is stored as text. | |
601 | However, you should also not expect non-numeric floating-point values | |
602 | such as infinity and \*(L"not a number\*(R" to pass successfully through a | |
603 | \&\fInstore()\fR/\fIretrieve()\fR pair. | |
604 | .PP | |
605 | As Storable neither knows nor cares about character sets (although it | |
606 | does know that characters may be more than eight bits wide), any difference | |
607 | in the interpretation of character codes between a host and a target | |
608 | system is your problem. In particular, if host and target use different | |
609 | code points to represent the characters used in the text representation | |
610 | of floating-point numbers, you will not be able be able to exchange | |
611 | floating-point data, even with \fInstore()\fR. | |
612 | .PP | |
613 | \&\f(CW\*(C`Storable::drop_utf8\*(C'\fR is a blunt tool. There is no facility either to | |
614 | return \fBall\fR strings as utf8 sequences, or to attempt to convert utf8 | |
615 | data back to 8 bit and \f(CW\*(C`croak()\*(C'\fR if the conversion fails. | |
616 | .PP | |
617 | Prior to Storable 2.01, no distinction was made between signed and | |
618 | unsigned integers on storing. By default Storable prefers to store a | |
619 | scalars string representation (if it has one) so this would only cause | |
620 | problems when storing large unsigned integers that had never been coverted | |
621 | to string or floating point. In other words values that had been generated | |
622 | by integer operations such as logic ops and then not used in any string or | |
623 | arithmetic context before storing. | |
624 | .Sh "64 bit data in perl 5.6.0 and 5.6.1" | |
625 | .IX Subsection "64 bit data in perl 5.6.0 and 5.6.1" | |
626 | This section only applies to you if you have existing data written out | |
627 | by Storable 2.02 or earlier on perl 5.6.0 or 5.6.1 on Unix or Linux which | |
628 | has been configured with 64 bit integer support (not the default) | |
629 | If you got a precompiled perl, rather than running Configure to build | |
630 | your own perl from source, then it almost certainly does not affect you, | |
631 | and you can stop reading now (unless you're curious). If you're using perl | |
632 | on Windows it does not affect you. | |
633 | .PP | |
634 | Storable writes a file header which contains the sizes of various C | |
635 | language types for the C compiler that built Storable (when not writing in | |
636 | network order), and will refuse to load files written by a Storable not | |
637 | on the same (or compatible) architecture. This check and a check on | |
638 | machine byteorder is needed because the size of various fields in the file | |
639 | are given by the sizes of the C language types, and so files written on | |
640 | different architectures are incompatible. This is done for increased speed. | |
641 | (When writing in network order, all fields are written out as standard | |
642 | lengths, which allows full interworking, but takes longer to read and write) | |
643 | .PP | |
644 | Perl 5.6.x introduced the ability to optional configure the perl interpreter | |
645 | to use C's \f(CW\*(C`long long\*(C'\fR type to allow scalars to store 64 bit integers on 32 | |
646 | bit systems. However, due to the way the Perl configuration system | |
647 | generated the C configuration files on non-Windows platforms, and the way | |
648 | Storable generates its header, nothing in the Storable file header reflected | |
649 | whether the perl writing was using 32 or 64 bit integers, despite the fact | |
650 | that Storable was storing some data differently in the file. Hence Storable | |
651 | running on perl with 64 bit integers will read the header from a file | |
652 | written by a 32 bit perl, not realise that the data is actually in a subtly | |
653 | incompatible format, and then go horribly wrong (possibly crashing) if it | |
654 | encountered a stored integer. This is a design failure. | |
655 | .PP | |
656 | Storable has now been changed to write out and read in a file header with | |
657 | information about the size of integers. It's impossible to detect whether | |
658 | an old file being read in was written with 32 or 64 bit integers (they have | |
659 | the same header) so it's impossible to automatically switch to a correct | |
660 | backwards compatibility mode. Hence this Storable defaults to the new, | |
661 | correct behaviour. | |
662 | .PP | |
663 | What this means is that if you have data written by Storable 1.x running | |
664 | on perl 5.6.0 or 5.6.1 configured with 64 bit integers on Unix or Linux | |
665 | then by default this Storable will refuse to read it, giving the error | |
666 | \&\fIByte order is not compatible\fR. If you have such data then you you | |
667 | should set \f(CW$Storable::interwork_56_64bit\fR to a true value to make this | |
668 | Storable read and write files with the old header. You should also | |
669 | migrate your data, or any older perl you are communicating with, to this | |
670 | current version of Storable. | |
671 | .PP | |
672 | If you don't have data written with specific configuration of perl described | |
673 | above, then you do not and should not do anything. Don't set the flag \- | |
674 | not only will Storable on an identically configured perl refuse to load them, | |
675 | but Storable a differently configured perl will load them believing them | |
676 | to be correct for it, and then may well fail or crash part way through | |
677 | reading them. | |
678 | .SH "CREDITS" | |
679 | .IX Header "CREDITS" | |
680 | Thank you to (in chronological order): | |
681 | .PP | |
682 | .Vb 13 | |
683 | \& Jarkko Hietaniemi <jhi@iki.fi> | |
684 | \& Ulrich Pfeifer <pfeifer@charly.informatik.uni-dortmund.de> | |
685 | \& Benjamin A. Holzman <bah@ecnvantage.com> | |
686 | \& Andrew Ford <A.Ford@ford-mason.co.uk> | |
687 | \& Gisle Aas <gisle@aas.no> | |
688 | \& Jeff Gresham <gresham_jeffrey@jpmorgan.com> | |
689 | \& Murray Nesbitt <murray@activestate.com> | |
690 | \& Marc Lehmann <pcg@opengroup.org> | |
691 | \& Justin Banks <justinb@wamnet.com> | |
692 | \& Jarkko Hietaniemi <jhi@iki.fi> (AGAIN, as perl 5.7.0 Pumpkin!) | |
693 | \& Salvador Ortiz Garcia <sog@msg.com.mx> | |
694 | \& Dominic Dunlop <domo@computer.org> | |
695 | \& Erik Haugan <erik@solbors.no> | |
696 | .Ve | |
697 | .PP | |
698 | for their bug reports, suggestions and contributions. | |
699 | .PP | |
700 | Benjamin Holzman contributed the tied variable support, Andrew Ford | |
701 | contributed the canonical order for hashes, and Gisle Aas fixed | |
702 | a few misunderstandings of mine regarding the perl internals, | |
703 | and optimized the emission of \*(L"tags\*(R" in the output streams by | |
704 | simply counting the objects instead of tagging them (leading to | |
705 | a binary incompatibility for the Storable image starting at version | |
706 | 0.6\-\-older images are, of course, still properly understood). | |
707 | Murray Nesbitt made Storable thread\-safe. Marc Lehmann added overloading | |
708 | and references to tied items support. | |
709 | .SH "AUTHOR" | |
710 | .IX Header "AUTHOR" | |
711 | Storable was written by Raphael Manfredi \fI<Raphael_Manfredi@pobox.com>\fR | |
712 | Maintenance is now done by the perl5\-porters \fI<perl5\-porters@perl.org>\fR | |
713 | .PP | |
714 | Please e\-mail us with problems, bug fixes, comments and complaints, | |
715 | although if you have complements you should send them to Raphael. | |
716 | Please don't e\-mail Raphael with problems, as he no longer works on | |
717 | Storable, and your message will be delayed while he forwards it to us. | |
718 | .SH "SEE ALSO" | |
719 | .IX Header "SEE ALSO" | |
720 | Clone. |