Commit | Line | Data |
---|---|---|
920dae64 AT |
1 | .\" Automatically generated by Pod::Man v1.37, Pod::Parser v1.32 |
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 "2001-09-21" "perl v5.8.8" "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 "CODE REFERENCES" | |
292 | .IX Header "CODE REFERENCES" | |
293 | Since Storable version 2.05, \s-1CODE\s0 references may be serialized with | |
294 | the help of B::Deparse. To enable this feature, set | |
295 | \&\f(CW$Storable::Deparse\fR to a true value. To enable deserializazion, | |
296 | \&\f(CW$Storable::Eval\fR should be set to a true value. Be aware that | |
297 | deserialization is done through \f(CW\*(C`eval\*(C'\fR, which is dangerous if the | |
298 | Storable file contains malicious data. You can set \f(CW$Storable::Eval\fR | |
299 | to a subroutine reference which would be used instead of \f(CW\*(C`eval\*(C'\fR. See | |
300 | below for an example using a Safe compartment for deserialization | |
301 | of \s-1CODE\s0 references. | |
302 | .PP | |
303 | If \f(CW$Storable::Deparse\fR and/or \f(CW$Storable::Eval\fR are set to false | |
304 | values, then the value of \f(CW$Storable::forgive_me\fR (see below) is | |
305 | respected while serializing and deserializing. | |
306 | .SH "FORWARD COMPATIBILITY" | |
307 | .IX Header "FORWARD COMPATIBILITY" | |
308 | This release of Storable can be used on a newer version of Perl to | |
309 | serialize data which is not supported by earlier Perls. By default, | |
310 | Storable will attempt to do the right thing, by \f(CW\*(C`croak()\*(C'\fRing if it | |
311 | encounters data that it cannot deserialize. However, the defaults | |
312 | can be changed as follows: | |
313 | .IP "utf8 data" 4 | |
314 | .IX Item "utf8 data" | |
315 | Perl 5.6 added support for Unicode characters with code points > 255, | |
316 | and Perl 5.8 has full support for Unicode characters in hash keys. | |
317 | Perl internally encodes strings with these characters using utf8, and | |
318 | Storable serializes them as utf8. By default, if an older version of | |
319 | Perl encounters a utf8 value it cannot represent, it will \f(CW\*(C`croak()\*(C'\fR. | |
320 | To change this behaviour so that Storable deserializes utf8 encoded | |
321 | values as the string of bytes (effectively dropping the \fIis_utf8\fR flag) | |
322 | set \f(CW$Storable::drop_utf8\fR to some \f(CW\*(C`TRUE\*(C'\fR value. This is a form of | |
323 | data loss, because with \f(CW$drop_utf8\fR true, it becomes impossible to tell | |
324 | whether the original data was the Unicode string, or a series of bytes | |
325 | that happen to be valid utf8. | |
326 | .IP "restricted hashes" 4 | |
327 | .IX Item "restricted hashes" | |
328 | Perl 5.8 adds support for restricted hashes, which have keys | |
329 | restricted to a given set, and can have values locked to be read only. | |
330 | By default, when Storable encounters a restricted hash on a perl | |
331 | that doesn't support them, it will deserialize it as a normal hash, | |
332 | silently discarding any placeholder keys and leaving the keys and | |
333 | all values unlocked. To make Storable \f(CW\*(C`croak()\*(C'\fR instead, set | |
334 | \&\f(CW$Storable::downgrade_restricted\fR to a \f(CW\*(C`FALSE\*(C'\fR value. To restore | |
335 | the default set it back to some \f(CW\*(C`TRUE\*(C'\fR value. | |
336 | .IP "files from future versions of Storable" 4 | |
337 | .IX Item "files from future versions of Storable" | |
338 | Earlier versions of Storable would immediately croak if they encountered | |
339 | a file with a higher internal version number than the reading Storable | |
340 | knew about. Internal version numbers are increased each time new data | |
341 | types (such as restricted hashes) are added to the vocabulary of the file | |
342 | format. This meant that a newer Storable module had no way of writing a | |
343 | file readable by an older Storable, even if the writer didn't store newer | |
344 | data types. | |
345 | .Sp | |
346 | This version of Storable will defer croaking until it encounters a data | |
347 | type in the file that it does not recognize. This means that it will | |
348 | continue to read files generated by newer Storable modules which are careful | |
349 | in what they write out, making it easier to upgrade Storable modules in a | |
350 | mixed environment. | |
351 | .Sp | |
352 | The old behaviour of immediate croaking can be re-instated by setting | |
353 | \&\f(CW$Storable::accept_future_minor\fR to some \f(CW\*(C`FALSE\*(C'\fR value. | |
354 | .PP | |
355 | All these variables have no effect on a newer Perl which supports the | |
356 | relevant feature. | |
357 | .SH "ERROR REPORTING" | |
358 | .IX Header "ERROR REPORTING" | |
359 | Storable uses the \*(L"exception\*(R" paradigm, in that it does not try to workaround | |
360 | failures: if something bad happens, an exception is generated from the | |
361 | caller's perspective (see Carp and \f(CW\*(C`croak()\*(C'\fR). Use eval {} to trap | |
362 | those exceptions. | |
363 | .PP | |
364 | When Storable croaks, it tries to report the error via the \f(CW\*(C`logcroak()\*(C'\fR | |
365 | routine from the \f(CW\*(C`Log::Agent\*(C'\fR package, if it is available. | |
366 | .PP | |
367 | Normal errors are reported by having \fIstore()\fR or \fIretrieve()\fR return \f(CW\*(C`undef\*(C'\fR. | |
368 | Such errors are usually I/O errors (or truncated stream errors at retrieval). | |
369 | .SH "WIZARDS ONLY" | |
370 | .IX Header "WIZARDS ONLY" | |
371 | .Sh "Hooks" | |
372 | .IX Subsection "Hooks" | |
373 | Any class may define hooks that will be called during the serialization | |
374 | and deserialization process on objects that are instances of that class. | |
375 | Those hooks can redefine the way serialization is performed (and therefore, | |
376 | how the symmetrical deserialization should be conducted). | |
377 | .PP | |
378 | Since we said earlier: | |
379 | .PP | |
380 | .Vb 1 | |
381 | \& dclone(.) = thaw(freeze(.)) | |
382 | .Ve | |
383 | .PP | |
384 | everything we say about hooks should also hold for deep cloning. However, | |
385 | hooks get to know whether the operation is a mere serialization, or a cloning. | |
386 | .PP | |
387 | Therefore, when serializing hooks are involved, | |
388 | .PP | |
389 | .Vb 1 | |
390 | \& dclone(.) <> thaw(freeze(.)) | |
391 | .Ve | |
392 | .PP | |
393 | Well, you could keep them in sync, but there's no guarantee it will always | |
394 | hold on classes somebody else wrote. Besides, there is little to gain in | |
395 | doing so: a serializing hook could keep only one attribute of an object, | |
396 | which is probably not what should happen during a deep cloning of that | |
397 | same object. | |
398 | .PP | |
399 | Here is the hooking interface: | |
400 | .ie n .IP """STORABLE_freeze""\fR \fIobj\fR, \fIcloning" 4 | |
401 | .el .IP "\f(CWSTORABLE_freeze\fR \fIobj\fR, \fIcloning\fR" 4 | |
402 | .IX Item "STORABLE_freeze obj, cloning" | |
403 | The serializing hook, called on the object during serialization. It can be | |
404 | inherited, or defined in the class itself, like any other method. | |
405 | .Sp | |
406 | Arguments: \fIobj\fR is the object to serialize, \fIcloning\fR is a flag indicating | |
407 | whether we're in a \fIdclone()\fR or a regular serialization via \fIstore()\fR or \fIfreeze()\fR. | |
408 | .Sp | |
409 | Returned value: A \s-1LIST\s0 \f(CW\*(C`($serialized, $ref1, $ref2, ...)\*(C'\fR where \f(CW$serialized\fR | |
410 | is the serialized form to be used, and the optional \f(CW$ref1\fR, \f(CW$ref2\fR, etc... are | |
411 | extra references that you wish to let the Storable engine serialize. | |
412 | .Sp | |
413 | At deserialization time, you will be given back the same \s-1LIST\s0, but all the | |
414 | extra references will be pointing into the deserialized structure. | |
415 | .Sp | |
416 | The \fBfirst time\fR the hook is hit in a serialization flow, you may have it | |
417 | return an empty list. That will signal the Storable engine to further | |
418 | discard that hook for this class and to therefore revert to the default | |
419 | serialization of the underlying Perl data. The hook will again be normally | |
420 | processed in the next serialization. | |
421 | .Sp | |
422 | Unless you know better, serializing hook should always say: | |
423 | .Sp | |
424 | .Vb 5 | |
425 | \& sub STORABLE_freeze { | |
426 | \& my ($self, $cloning) = @_; | |
427 | \& return if $cloning; # Regular default serialization | |
428 | \& .... | |
429 | \& } | |
430 | .Ve | |
431 | .Sp | |
432 | in order to keep reasonable \fIdclone()\fR semantics. | |
433 | .ie n .IP """STORABLE_thaw""\fR \fIobj\fR, \fIcloning\fR, \fIserialized, ..." 4 | |
434 | .el .IP "\f(CWSTORABLE_thaw\fR \fIobj\fR, \fIcloning\fR, \fIserialized\fR, ..." 4 | |
435 | .IX Item "STORABLE_thaw obj, cloning, serialized, ..." | |
436 | The deserializing hook called on the object during deserialization. | |
437 | But wait: if we're deserializing, there's no object yet... right? | |
438 | .Sp | |
439 | Wrong: the Storable engine creates an empty one for you. If you know Eiffel, | |
440 | you can view \f(CW\*(C`STORABLE_thaw\*(C'\fR as an alternate creation routine. | |
441 | .Sp | |
442 | This means the hook can be inherited like any other method, and that | |
443 | \&\fIobj\fR is your blessed reference for this particular instance. | |
444 | .Sp | |
445 | The other arguments should look familiar if you know \f(CW\*(C`STORABLE_freeze\*(C'\fR: | |
446 | \&\fIcloning\fR is true when we're part of a deep clone operation, \fIserialized\fR | |
447 | is the serialized string you returned to the engine in \f(CW\*(C`STORABLE_freeze\*(C'\fR, | |
448 | and there may be an optional list of references, in the same order you gave | |
449 | them at serialization time, pointing to the deserialized objects (which | |
450 | have been processed courtesy of the Storable engine). | |
451 | .Sp | |
452 | When the Storable engine does not find any \f(CW\*(C`STORABLE_thaw\*(C'\fR hook routine, | |
453 | it tries to load the class by requiring the package dynamically (using | |
454 | the blessed package name), and then re-attempts the lookup. If at that | |
455 | time the hook cannot be located, the engine croaks. Note that this mechanism | |
456 | will fail if you define several classes in the same file, but perlmod | |
457 | warned you. | |
458 | .Sp | |
459 | It is up to you to use this information to populate \fIobj\fR the way you want. | |
460 | .Sp | |
461 | Returned value: none. | |
462 | .ie n .IP """STORABLE_attach""\fR \fIclass\fR, \fIcloning\fR, \fIserialized" 4 | |
463 | .el .IP "\f(CWSTORABLE_attach\fR \fIclass\fR, \fIcloning\fR, \fIserialized\fR" 4 | |
464 | .IX Item "STORABLE_attach class, cloning, serialized" | |
465 | While \f(CW\*(C`STORABLE_freeze\*(C'\fR and \f(CW\*(C`STORABLE_thaw\*(C'\fR are useful for classes where | |
466 | each instance is independant, this mechanism has difficulty (or is | |
467 | incompatible) with objects that exist as common process-level or | |
468 | system-level resources, such as singleton objects, database pools, caches | |
469 | or memoized objects. | |
470 | .Sp | |
471 | The alternative \f(CW\*(C`STORABLE_attach\*(C'\fR method provides a solution for these | |
472 | shared objects. Instead of \f(CW\*(C`STORABLE_freeze\*(C'\fR \-\-E<GT> \f(CW\*(C`STORABLE_thaw\*(C'\fR, | |
473 | you implement \f(CW\*(C`STORABLE_freeze\*(C'\fR \-\-E<GT> \f(CW\*(C`STORABLE_attach\*(C'\fR instead. | |
474 | .Sp | |
475 | Arguments: \fIclass\fR is the class we are attaching to, \fIcloning\fR is a flag | |
476 | indicating whether we're in a \fIdclone()\fR or a regular de-serialization via | |
477 | \&\fIthaw()\fR, and \fIserialized\fR is the stored string for the resource object. | |
478 | .Sp | |
479 | Because these resource objects are considered to be owned by the entire | |
480 | process/system, and not the \*(L"property\*(R" of whatever is being serialized, | |
481 | no references underneath the object should be included in the serialized | |
482 | string. Thus, in any class that implements \f(CW\*(C`STORABLE_attach\*(C'\fR, the | |
483 | \&\f(CW\*(C`STORABLE_freeze\*(C'\fR method cannot return any references, and \f(CW\*(C`Storable\*(C'\fR | |
484 | will throw an error if \f(CW\*(C`STORABLE_freeze\*(C'\fR tries to return references. | |
485 | .Sp | |
486 | All information required to \*(L"attach\*(R" back to the shared resource object | |
487 | \&\fBmust\fR be contained \fBonly\fR in the \f(CW\*(C`STORABLE_freeze\*(C'\fR return string. | |
488 | Otherwise, \f(CW\*(C`STORABLE_freeze\*(C'\fR behaves as normal for \f(CW\*(C`STORABLE_attach\*(C'\fR | |
489 | classes. | |
490 | .Sp | |
491 | Because \f(CW\*(C`STORABLE_attach\*(C'\fR is passed the class (rather than an object), | |
492 | it also returns the object directly, rather than modifying the passed | |
493 | object. | |
494 | .Sp | |
495 | Returned value: object of type \f(CW\*(C`class\*(C'\fR | |
496 | .Sh "Predicates" | |
497 | .IX Subsection "Predicates" | |
498 | Predicates are not exportable. They must be called by explicitly prefixing | |
499 | them with the Storable package name. | |
500 | .ie n .IP """Storable::last_op_in_netorder""" 4 | |
501 | .el .IP "\f(CWStorable::last_op_in_netorder\fR" 4 | |
502 | .IX Item "Storable::last_op_in_netorder" | |
503 | The \f(CW\*(C`Storable::last_op_in_netorder()\*(C'\fR predicate will tell you whether | |
504 | network order was used in the last store or retrieve operation. If you | |
505 | don't know how to use this, just forget about it. | |
506 | .ie n .IP """Storable::is_storing""" 4 | |
507 | .el .IP "\f(CWStorable::is_storing\fR" 4 | |
508 | .IX Item "Storable::is_storing" | |
509 | Returns true if within a store operation (via STORABLE_freeze hook). | |
510 | .ie n .IP """Storable::is_retrieving""" 4 | |
511 | .el .IP "\f(CWStorable::is_retrieving\fR" 4 | |
512 | .IX Item "Storable::is_retrieving" | |
513 | Returns true if within a retrieve operation (via STORABLE_thaw hook). | |
514 | .Sh "Recursion" | |
515 | .IX Subsection "Recursion" | |
516 | With hooks comes the ability to recurse back to the Storable engine. | |
517 | Indeed, hooks are regular Perl code, and Storable is convenient when | |
518 | it comes to serializing and deserializing things, so why not use it | |
519 | to handle the serialization string? | |
520 | .PP | |
521 | There are a few things you need to know, however: | |
522 | .IP "\(bu" 4 | |
523 | You can create endless loops if the things you serialize via \fIfreeze()\fR | |
524 | (for instance) point back to the object we're trying to serialize in | |
525 | the hook. | |
526 | .IP "\(bu" 4 | |
527 | Shared references among objects will not stay shared: if we're serializing | |
528 | the list of object [A, C] where both object A and C refer to the \s-1SAME\s0 object | |
529 | B, and if there is a serializing hook in A that says freeze(B), then when | |
530 | deserializing, we'll get [A', C'] where A' refers to B', but C' refers to D, | |
531 | a deep clone of B'. The topology was not preserved. | |
532 | .PP | |
533 | That's why \f(CW\*(C`STORABLE_freeze\*(C'\fR lets you provide a list of references | |
534 | to serialize. The engine guarantees that those will be serialized in the | |
535 | same context as the other objects, and therefore that shared objects will | |
536 | stay shared. | |
537 | .PP | |
538 | In the above [A, C] example, the \f(CW\*(C`STORABLE_freeze\*(C'\fR hook could return: | |
539 | .PP | |
540 | .Vb 1 | |
541 | \& ("something", $self->{B}) | |
542 | .Ve | |
543 | .PP | |
544 | and the B part would be serialized by the engine. In \f(CW\*(C`STORABLE_thaw\*(C'\fR, you | |
545 | would get back the reference to the B' object, deserialized for you. | |
546 | .PP | |
547 | Therefore, recursion should normally be avoided, but is nonetheless supported. | |
548 | .Sh "Deep Cloning" | |
549 | .IX Subsection "Deep Cloning" | |
550 | There is a Clone module available on \s-1CPAN\s0 which implements deep cloning | |
551 | natively, i.e. without freezing to memory and thawing the result. It is | |
552 | aimed to replace Storable's \fIdclone()\fR some day. However, it does not currently | |
553 | support Storable hooks to redefine the way deep cloning is performed. | |
554 | .SH "Storable magic" | |
555 | .IX Header "Storable magic" | |
556 | Yes, there's a lot of that :\-) But more precisely, in \s-1UNIX\s0 systems | |
557 | there's a utility called \f(CW\*(C`file\*(C'\fR, which recognizes data files based on | |
558 | their contents (usually their first few bytes). For this to work, | |
559 | a certain file called \fImagic\fR needs to taught about the \fIsignature\fR | |
560 | of the data. Where that configuration file lives depends on the \s-1UNIX\s0 | |
561 | flavour; often it's something like \fI/usr/share/misc/magic\fR or | |
562 | \&\fI/etc/magic\fR. Your system administrator needs to do the updating of | |
563 | the \fImagic\fR file. The necessary signature information is output to | |
564 | \&\s-1STDOUT\s0 by invoking \fIStorable::show_file_magic()\fR. Note that the \s-1GNU\s0 | |
565 | implementation of the \f(CW\*(C`file\*(C'\fR utility, version 3.38 or later, | |
566 | is expected to contain support for recognising Storable files | |
567 | out\-of\-the\-box, in addition to other kinds of Perl files. | |
568 | .SH "EXAMPLES" | |
569 | .IX Header "EXAMPLES" | |
570 | Here are some code samples showing a possible usage of Storable: | |
571 | .PP | |
572 | .Vb 1 | |
573 | \& use Storable qw(store retrieve freeze thaw dclone); | |
574 | .Ve | |
575 | .PP | |
576 | .Vb 1 | |
577 | \& %color = ('Blue' => 0.1, 'Red' => 0.8, 'Black' => 0, 'White' => 1); | |
578 | .Ve | |
579 | .PP | |
580 | .Vb 1 | |
581 | \& store(\e%color, 'mycolors') or die "Can't store %a in mycolors!\en"; | |
582 | .Ve | |
583 | .PP | |
584 | .Vb 3 | |
585 | \& $colref = retrieve('mycolors'); | |
586 | \& die "Unable to retrieve from mycolors!\en" unless defined $colref; | |
587 | \& printf "Blue is still %lf\en", $colref->{'Blue'}; | |
588 | .Ve | |
589 | .PP | |
590 | .Vb 1 | |
591 | \& $colref2 = dclone(\e%color); | |
592 | .Ve | |
593 | .PP | |
594 | .Vb 3 | |
595 | \& $str = freeze(\e%color); | |
596 | \& printf "Serialization of %%color is %d bytes long.\en", length($str); | |
597 | \& $colref3 = thaw($str); | |
598 | .Ve | |
599 | .PP | |
600 | which prints (on my machine): | |
601 | .PP | |
602 | .Vb 2 | |
603 | \& Blue is still 0.100000 | |
604 | \& Serialization of %color is 102 bytes long. | |
605 | .Ve | |
606 | .PP | |
607 | Serialization of \s-1CODE\s0 references and deserialization in a safe | |
608 | compartment: | |
609 | .PP | |
610 | .Vb 11 | |
611 | \& use Storable qw(freeze thaw); | |
612 | \& use Safe; | |
613 | \& use strict; | |
614 | \& my $safe = new Safe; | |
615 | \& # because of opcodes used in "use strict": | |
616 | \& $safe->permit(qw(:default require)); | |
617 | \& local $Storable::Deparse = 1; | |
618 | \& local $Storable::Eval = sub { $safe->reval($_[0]) }; | |
619 | \& my $serialized = freeze(sub { 42 }); | |
620 | \& my $code = thaw($serialized); | |
621 | \& $code->() == 42; | |
622 | .Ve | |
623 | .SH "WARNING" | |
624 | .IX Header "WARNING" | |
625 | If you're using references as keys within your hash tables, you're bound | |
626 | to be disappointed when retrieving your data. Indeed, Perl stringifies | |
627 | references used as hash table keys. If you later wish to access the | |
628 | items via another reference stringification (i.e. using the same | |
629 | reference that was used for the key originally to record the value into | |
630 | the hash table), it will work because both references stringify to the | |
631 | same string. | |
632 | .PP | |
633 | It won't work across a sequence of \f(CW\*(C`store\*(C'\fR and \f(CW\*(C`retrieve\*(C'\fR operations, | |
634 | however, because the addresses in the retrieved objects, which are | |
635 | part of the stringified references, will probably differ from the | |
636 | original addresses. The topology of your structure is preserved, | |
637 | but not hidden semantics like those. | |
638 | .PP | |
639 | On platforms where it matters, be sure to call \f(CW\*(C`binmode()\*(C'\fR on the | |
640 | descriptors that you pass to Storable functions. | |
641 | .PP | |
642 | Storing data canonically that contains large hashes can be | |
643 | significantly slower than storing the same data normally, as | |
644 | temporary arrays to hold the keys for each hash have to be allocated, | |
645 | populated, sorted and freed. Some tests have shown a halving of the | |
646 | speed of storing \*(-- the exact penalty will depend on the complexity of | |
647 | your data. There is no slowdown on retrieval. | |
648 | .SH "BUGS" | |
649 | .IX Header "BUGS" | |
650 | You can't store \s-1GLOB\s0, \s-1FORMLINE\s0, etc.... If you can define semantics | |
651 | for those operations, feel free to enhance Storable so that it can | |
652 | deal with them. | |
653 | .PP | |
654 | The store functions will \f(CW\*(C`croak\*(C'\fR if they run into such references | |
655 | unless you set \f(CW$Storable::forgive_me\fR to some \f(CW\*(C`TRUE\*(C'\fR value. In that | |
656 | case, the fatal message is turned in a warning and some | |
657 | meaningless string is stored instead. | |
658 | .PP | |
659 | Setting \f(CW$Storable::canonical\fR may not yield frozen strings that | |
660 | compare equal due to possible stringification of numbers. When the | |
661 | string version of a scalar exists, it is the form stored; therefore, | |
662 | if you happen to use your numbers as strings between two freezing | |
663 | operations on the same data structures, you will get different | |
664 | results. | |
665 | .PP | |
666 | When storing doubles in network order, their value is stored as text. | |
667 | However, you should also not expect non-numeric floating-point values | |
668 | such as infinity and \*(L"not a number\*(R" to pass successfully through a | |
669 | \&\fInstore()\fR/\fIretrieve()\fR pair. | |
670 | .PP | |
671 | As Storable neither knows nor cares about character sets (although it | |
672 | does know that characters may be more than eight bits wide), any difference | |
673 | in the interpretation of character codes between a host and a target | |
674 | system is your problem. In particular, if host and target use different | |
675 | code points to represent the characters used in the text representation | |
676 | of floating-point numbers, you will not be able be able to exchange | |
677 | floating-point data, even with \fInstore()\fR. | |
678 | .PP | |
679 | \&\f(CW\*(C`Storable::drop_utf8\*(C'\fR is a blunt tool. There is no facility either to | |
680 | return \fBall\fR strings as utf8 sequences, or to attempt to convert utf8 | |
681 | data back to 8 bit and \f(CW\*(C`croak()\*(C'\fR if the conversion fails. | |
682 | .PP | |
683 | Prior to Storable 2.01, no distinction was made between signed and | |
684 | unsigned integers on storing. By default Storable prefers to store a | |
685 | scalars string representation (if it has one) so this would only cause | |
686 | problems when storing large unsigned integers that had never been coverted | |
687 | to string or floating point. In other words values that had been generated | |
688 | by integer operations such as logic ops and then not used in any string or | |
689 | arithmetic context before storing. | |
690 | .Sh "64 bit data in perl 5.6.0 and 5.6.1" | |
691 | .IX Subsection "64 bit data in perl 5.6.0 and 5.6.1" | |
692 | This section only applies to you if you have existing data written out | |
693 | by Storable 2.02 or earlier on perl 5.6.0 or 5.6.1 on Unix or Linux which | |
694 | has been configured with 64 bit integer support (not the default) | |
695 | If you got a precompiled perl, rather than running Configure to build | |
696 | your own perl from source, then it almost certainly does not affect you, | |
697 | and you can stop reading now (unless you're curious). If you're using perl | |
698 | on Windows it does not affect you. | |
699 | .PP | |
700 | Storable writes a file header which contains the sizes of various C | |
701 | language types for the C compiler that built Storable (when not writing in | |
702 | network order), and will refuse to load files written by a Storable not | |
703 | on the same (or compatible) architecture. This check and a check on | |
704 | machine byteorder is needed because the size of various fields in the file | |
705 | are given by the sizes of the C language types, and so files written on | |
706 | different architectures are incompatible. This is done for increased speed. | |
707 | (When writing in network order, all fields are written out as standard | |
708 | lengths, which allows full interworking, but takes longer to read and write) | |
709 | .PP | |
710 | Perl 5.6.x introduced the ability to optional configure the perl interpreter | |
711 | to use C's \f(CW\*(C`long long\*(C'\fR type to allow scalars to store 64 bit integers on 32 | |
712 | bit systems. However, due to the way the Perl configuration system | |
713 | generated the C configuration files on non-Windows platforms, and the way | |
714 | Storable generates its header, nothing in the Storable file header reflected | |
715 | whether the perl writing was using 32 or 64 bit integers, despite the fact | |
716 | that Storable was storing some data differently in the file. Hence Storable | |
717 | running on perl with 64 bit integers will read the header from a file | |
718 | written by a 32 bit perl, not realise that the data is actually in a subtly | |
719 | incompatible format, and then go horribly wrong (possibly crashing) if it | |
720 | encountered a stored integer. This is a design failure. | |
721 | .PP | |
722 | Storable has now been changed to write out and read in a file header with | |
723 | information about the size of integers. It's impossible to detect whether | |
724 | an old file being read in was written with 32 or 64 bit integers (they have | |
725 | the same header) so it's impossible to automatically switch to a correct | |
726 | backwards compatibility mode. Hence this Storable defaults to the new, | |
727 | correct behaviour. | |
728 | .PP | |
729 | What this means is that if you have data written by Storable 1.x running | |
730 | on perl 5.6.0 or 5.6.1 configured with 64 bit integers on Unix or Linux | |
731 | then by default this Storable will refuse to read it, giving the error | |
732 | \&\fIByte order is not compatible\fR. If you have such data then you you | |
733 | should set \f(CW$Storable::interwork_56_64bit\fR to a true value to make this | |
734 | Storable read and write files with the old header. You should also | |
735 | migrate your data, or any older perl you are communicating with, to this | |
736 | current version of Storable. | |
737 | .PP | |
738 | If you don't have data written with specific configuration of perl described | |
739 | above, then you do not and should not do anything. Don't set the flag \- | |
740 | not only will Storable on an identically configured perl refuse to load them, | |
741 | but Storable a differently configured perl will load them believing them | |
742 | to be correct for it, and then may well fail or crash part way through | |
743 | reading them. | |
744 | .SH "CREDITS" | |
745 | .IX Header "CREDITS" | |
746 | Thank you to (in chronological order): | |
747 | .PP | |
748 | .Vb 13 | |
749 | \& Jarkko Hietaniemi <jhi@iki.fi> | |
750 | \& Ulrich Pfeifer <pfeifer@charly.informatik.uni-dortmund.de> | |
751 | \& Benjamin A. Holzman <bah@ecnvantage.com> | |
752 | \& Andrew Ford <A.Ford@ford-mason.co.uk> | |
753 | \& Gisle Aas <gisle@aas.no> | |
754 | \& Jeff Gresham <gresham_jeffrey@jpmorgan.com> | |
755 | \& Murray Nesbitt <murray@activestate.com> | |
756 | \& Marc Lehmann <pcg@opengroup.org> | |
757 | \& Justin Banks <justinb@wamnet.com> | |
758 | \& Jarkko Hietaniemi <jhi@iki.fi> (AGAIN, as perl 5.7.0 Pumpkin!) | |
759 | \& Salvador Ortiz Garcia <sog@msg.com.mx> | |
760 | \& Dominic Dunlop <domo@computer.org> | |
761 | \& Erik Haugan <erik@solbors.no> | |
762 | .Ve | |
763 | .PP | |
764 | for their bug reports, suggestions and contributions. | |
765 | .PP | |
766 | Benjamin Holzman contributed the tied variable support, Andrew Ford | |
767 | contributed the canonical order for hashes, and Gisle Aas fixed | |
768 | a few misunderstandings of mine regarding the perl internals, | |
769 | and optimized the emission of \*(L"tags\*(R" in the output streams by | |
770 | simply counting the objects instead of tagging them (leading to | |
771 | a binary incompatibility for the Storable image starting at version | |
772 | 0.6\-\-older images are, of course, still properly understood). | |
773 | Murray Nesbitt made Storable thread\-safe. Marc Lehmann added overloading | |
774 | and references to tied items support. | |
775 | .SH "AUTHOR" | |
776 | .IX Header "AUTHOR" | |
777 | Storable was written by Raphael Manfredi \fI<Raphael_Manfredi@pobox.com>\fR | |
778 | Maintenance is now done by the perl5\-porters \fI<perl5\-porters@perl.org>\fR | |
779 | .PP | |
780 | Please e\-mail us with problems, bug fixes, comments and complaints, | |
781 | although if you have complements you should send them to Raphael. | |
782 | Please don't e\-mail Raphael with problems, as he no longer works on | |
783 | Storable, and your message will be delayed while he forwards it to us. | |
784 | .SH "SEE ALSO" | |
785 | .IX Header "SEE ALSO" | |
786 | Clone. |