Cleanup capabilities

[marc-mabe]

Some of the current defined capabilities are very hard to understand/useless and I would like to define some of them.

minTtl
This defines the minimum supported TTL which is clear but only a handful people knows that this also defines the general TTL support.

• 0 means TTL is supported

• 0 means TTL is not supported and all other TTL related capabilities can be ignored

There is no adapter having another value than 0 or 1 so this can be renamed to ttlSupported with bool.

-> minTtl needs to be still available for BC reasons until the next major but can be marked deprecated.

staticTtl
This defines how the expiration time will be calculated which is not a meaningful description.

• true means the expiration time will be calculated on read using the last-modification-time of the item, the current time and the current TTL option
• false means the expiration time will be calculated using the current TTL and the current time. It will be stored together with the item

Thoughts for better names ?

expiredRead
There was the idea that it is possible to read an expired item by setting changing the TTL (like to 0 = infinitive) but this only works with staticTtl=true to make it possible using an expired item in cases regeneration breaks (like on failed DB connection).

This is a useless capability because changing the TTL to something else automatically changes the expiration time of all stored items if staticTtl=true which means in case for infinity the item is no longer expired. -> Bam the item is no longer expired but this capability is for reading expired items and the nature of staticTtl already defines this behavior.

-> I would like to deprecate this capability and remove it in the next major version.

@kynx @Maks3w @Ocramius @ezimuel Thoughts ?

[kynx]

staticTtl

Perhaps ttlOnRead?

While we're there, the format for supportedDatatypes is pretty confusing:

'object' => true, // OK, we can store objects
'object' => 'object', // OK, as above
'integer' => true, // OK, we can store integers
'integer' => 'string', // they're stored as strings (redis)
'integer' => 'integer', // huh? stored as string (memcache), but you wouldn't know it

Maybe the last is a bug, or maybe I'm missing something. I can see some value in being able say "yes, the adapter will store it, but won't return the same type", but true / false / returned type would be clearer.

[marc-mabe]

@kynx The idea behind this is as follows:

• true: Variable of this type will be stores as is and the following will be true:

$value = 100;
$storage->setItem('key', $value);
var_dump($value == $storage->getItem('key')); // true
var_dump($value === $storage->getItem('key')); // true

• {type}: Variables of this type will be serialized and the following will be true:

$value = new stdClass;
$storage->setItem('key', $value);
var_dump($value == $storage->getItem('key')); // true
var_dump($value === $storage->getItem('key')); // false

• false: Variable of this type can't be stored

In case for integer it should be true / false only because an integer will be same in strict mode if it's the same in non strict mode.

[weierophinney]

This repository has been closed and moved to laminas/laminas-cache; a new issue has been opened at laminas/laminas-cache#8.