| Summary | Kolab Storage: serialize/unserialize handling |
| Queue | Horde Framework Packages |
| Queue Version | Git master |
| Type | Bug |
| State | Assigned |
| Priority | 1. Low |
| Owners | wrobel (at) horde (dot) org |
| Requester | thomas.jarosch (at) intra2net (dot) com |
| Created | 11/09/2012 (4569 days ago) |
| Due | |
| Updated | 11/22/2012 (4556 days ago) |
| Assigned | 11/09/2012 (4569 days ago) |
| Resolved | |
| Milestone | 3 |
| Patch | No |
The deserialization currently happens in
Horde/Kolab/Storage/Data/Cached.php on line 228.
This issue will be fixed when I finished the redesign of the data
area. Horde 6.0 though as this is an API change.
State ⇒ Assigned
Priority ⇒ 1. Low
Patch ⇒ No
Milestone ⇒
Queue ⇒ Horde Framework Packages
Summary ⇒ Kolab Storage: serialize/unserialize handling
Type ⇒ Bug
State ⇒ Unconfirmed
I'm not sure how the serialize/unserialize handling is done in Kolab_Storage.
Let's take Storage/Cache/Data.php as an example.
The code in store() looks like this:
---------------------------------------------------
$this->_data[self::STAMP] = serialize($stamp);
---------------------------------------------------
The _load() code does nothing special to the "self::STAMP" field.
The getStamp() code looks like this:
----------------------------------------------
public function getStamp()
{
$this->_checkInit(self::STAMP);
return $this->_data[self::STAMP];
}
----------------------------------------------
Is there some recursive unserialize magic happening I don't see yet?
IMHO if you call getStamp(), it will return garbage.
The same code pattern applies to a few other spots.
OTOH the actual user of "Storage/Cache/Data.php" is "Storage/Data/Cached.php".
That one unserializes the stamp before using it.
Is this a performance optimization to move unserialize() to the calling side?
Thomas