[#11680] Kolab Storage: serialize/unserialize handling
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)
Updated 2012-11-22 (3225 days ago)
Assigned 2012-11-09 (3238 days ago)
Milestone 3
Patch No

2012-11-22 18:56:16 Gunnar Wrobel Milestone ⇒ 3
2012-11-22 18:55:31 Gunnar Wrobel Comment #2 Reply to this comment
While this is undeniably broken and certainly not intended:

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.
2012-11-09 15:43:49 Thomas Jarosch Assigned to Gunnar Wrobel
State ⇒ Assigned
2012-11-09 15:43:28 Thomas Jarosch Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 1. Low
Summary ⇒ Kolab Storage: serialize/unserialize handling
Queue ⇒ Horde Framework Packages
Milestone ⇒
Patch ⇒ No
Reply to this comment
Hi Gunnar,

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()
         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?


Saved Queries