From: php at prog dot hu Operating system: PHP version: 5.3.0RC1 PHP Bug Type: Feature/Change Request Bug description: Make serialize()d objects shorter by omitting default values
Description: ------------ This entry is about a feature request for the extension of the serialize() function, to optinally enable applications to store their persisent objects in a shorter, more efficient way than now. Currently serialize() stores all member fields of the objects in the output string, even if most of those member fields still have their default values as defined in their appropriate class' defintion. This is a waste of storage space and processing power at re-parse time (deserialization). Applications therefore should have the option to tell PHP to store only those member fields in serialized object descriptions, which have non-default values. This could be achieved by adding a second, optional parameter to serialize(), which (if set to true for ex) would invoke this "optimized" behaviour. Reloading (deserialization)of the objects stored in this "optimized" format should occour the same way as now (with a regular unserialize()). The modification I'm proposing has practically no compatibility impacts, as serialize() currently has no second parameter, so old code would still emit full object defintions (with all member fields included, even those with default values), and provide byte-to-byte the same output as in older version. Also unserialization would require no code change, since even in current PHP implementations, if a member field is not included in the string passed to unserialize(), the value of the field in the returned object will default to the value set forth in the class defintion field (if any). That means that the same unserialize() call could take both the old "full" and the new "optimized" strings, and would construct exactly the same object from them, provided the member fields' definitions in the class file wasn't changed in regard to the default values of those field (that's why we need to make the change optional, so applications developers can meet their choice whether they prefer speed/storage space benefits over strict compatibility, especially, that the latter one can be taken care of from application code, too). -- Edit bug report at http://bugs.php.net/?id=48100&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48100&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48100&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48100&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48100&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48100&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48100&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48100&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48100&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48100&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48100&r=support Expected behavior: http://bugs.php.net/fix.php?id=48100&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48100&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48100&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48100&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48100&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=48100&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48100&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48100&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48100&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48100&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48100&r=mysqlcfg
