| 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. |