| 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 | 2012-11-09 (3238 days ago) |
| Due | |
| Updated | 2012-11-22 (3225 days ago) |
| Assigned | 2012-11-09 (3238 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
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 1. Low
Summary ⇒ Kolab Storage: serialize/unserialize handling
Queue ⇒ Horde Framework Packages
Milestone ⇒
Patch ⇒ No
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