apix/cache

A thin PSR-6 cache wrapper with a generic interface to various caching backends emphasising cache tagging and indexing.

cache's Issues

Travis: PHP 7.0 with `memcached` -- not yet officially supported?

Memcached for PHP 7.0 does not currently work with Travis build.

See: https://travis-ci.org/frqnck/apix-cache/jobs/142451500

Affects:

PHP Version: 7.0
Extension: memcached

TaggablePool and Pool overrides prefix_key and prefix_tag options with hardcoded values

Hello,

I am looking at an issue when creating a pool using a factory, if I set the 'prefix_key' and 'prefix_tag' options they are overriden with hardcoded values: 'apix-key-' and 'apix-tag-'.

Apparently this happens in the constructors of TaggablePool and Pool. I would suggest to pass maybe just the 'taggable' boolean attribute to the adapters, and maybe not include the prefixes :)

Regards,
Alex

Travis: PHP 5.3 with `memcached` -- broken

Memcached for PHP 5.3 no longer working with Travis build.

See: https://travis-ci.org/frqnck/apix-cache/jobs/142451472

Affects:

• PHP Version: 5.3
• Extension: memcached

Uncaught Apix\Cache\PsrCache\InvalidArgumentException: Item key ('test:string') is invalid

Bug Report

Uncaught Apix\Cache\PsrCache\InvalidArgumentException: Item key ('test:string') is invalid

Code snippet

use Apix\Cache;

$backend = new \Redis();
$backend->connect('localhost');
$backend->select(1);
$cache = Cache\Factory::getPool($backend);

$item = $cache->getItem('test:string');

returns:

PHP Fatal error:  Uncaught Apix\Cache\PsrCache\InvalidArgumentException: Item key ('test:string') is invalid. in 
./vendor/apix/cache/src/PsrCache/Item.php:71
Stack trace:
#0 /vendor/apix/cache/src/PsrCache/Pool.php(53): Apix\Cache\PsrCache\Item::normalizedKey()
#1 /test_redis_apix.php(17): Apix\Cache\PsrCache\Pool->getItem()
#2 {main}
  thrown in /vendor/apix/cache/src/PsrCache/Item.php on line 71

But Redis allowed use this key:

root@quartz:/etc/redis# redis-cli --version
redis-cli 6.2.6

root@quartz:/etc/redis# redis-cli

127.0.0.1:6379> set test:string 'foobar'
OK
127.0.0.1:6379> get test:string
"foobar"
127.0.0.1:6379> 

Also, keys with : recommended by official documentation: https://redis.io/topics/data-types-intro#redis-keys

Very short keys are often not a good idea. There is little point in writing "u1000flw" as a key if you can instead write "user:1000:followers". The latter is more readable and the added space is minor compared to the space used by the key object itself and the value object. While short keys will obviously consume a bit less memory, your job is to find the right balance.

More details

• Apix-cache version: 1.3
• Operating System: LMDE (based debian 10)
• PHP Version: 7.4
• Redis 6.2.6

Travis: PHP 5.4 and 5.5 cannot run on Xenial

Bug Report

Description

Travis-CI builds are currently run on Xenial which doesn't support PHP 5.4 and 5.5.

`Apix\Redis::flush()` use Redis KEYS

From Redis Documentation:

Warning: consider KEYS as a command that should only be used in production environments with extreme care. It may ruin performance when it is executed against large databases. This command is intended for debugging and special operations, such as changing your keyspace layout. Don't use KEYS in your regular application code. If you're looking for a way to find keys in a subset of your keyspace, consider using SCAN or sets.

The Redis module probably shouldn't be using the keys command - could probably be replaced with a private function that runs a scan on a pattern and compiles those lists.

Support PHP 7.4

Feature Proposal

Description

Add PHP 7.4 to the Travis build and make any code changes necessary to run on PHP 7.4 (while continuing to support currently supported versions of PHP)

• Apix-cache version: 1.3.x
• Operating System: any
• PHP Version: PHP 7.4, 7.3, 7.2, 7.1, 7.0, 5.6, 5.5, 5.4, & 5.3

Please add support for APCu

Since APC as a caching engine is no longer supported, please add support for APCu. This could be as simple as cloning your APC class and renaming the methods to apcu_*

Adding `increment` and `decrement` methods?

Do you have thoughts about adding a standard "increment" function for the AbstractCache.php in apix-cache? I know that both Redis and Memcached have this function, and its something I need at the moment -- using ->getAdapter()->... Instead.
Jonathan

Adding increment/decrement methods to AbstractCache.php would be useful indeed.

It would be good to have a base/inhertied implementations generic enough so that backends without dedicated functions would still benefit.

PDO, Runtime and Filesystem(s) don’t have dedicated (in|de)crementors — the rest do.

Essentially, a base implementations would be a two steps affair, i.e. retrieve and update/upsert a (numerical) value. The default (in|de)cremental value being 1.

Travis: HHVM with the new `mongodb` -- extension not compiling

mongodb extension for HHVM does not currently work with Travis build.

See: https://travis-ci.org/frqnck/apix-cache/jobs/171382299

Affects:

HHVM Version: 3.6.6
Extension: mongodb

'Files' and 'Directory' are not listed as clients in the Factory class

Hello,

Apparently the 'Files' and 'Directory' clients are not listed in the Factory, thus we cannot instantiate a factory by passing a string like 'files' or 'directory'. Also, the first argument in the implementation of those 2 classes should be an instance of the class itself, otherwise the factory will throw an error.

Maybe I missed something?!

Thanks,
Regards,
Alex

Files cache not correctly handling EOL on Windows

Hello,

Whenever I try to read a cache file generated through Files on Windows, I get a miss with the following PHP notice:
PHP Notice: unserialize(): Error at offset 0 of 3224505 bytes in D:....\vendor\apix\cache\src\Files.php on line 70

I realized that Files::loadKey relies on the assumption that PHP_EOL (used for adding key and expiration to the cache entry) is of size 1, which is not the case on Windows (\r\n).
Just to check that it was indeed the issue, I changed 2 lines in Files::loadKey to have:
$pos+strlen(PHP_EOL)
instead of:
$pos+1

and the unserialize function returned correctly this time.
I'm not sure this is the only occurence of the issue.

Could it be possible to have a fix for this?

Best regards,

Davy

AbstractPdo::flush() drops the cache table on flush(true)

Bug Report

The implementation of the AbstractPdo classes drops the cache table on flush(true). This results on a exception being thrown if the cache is subsequently accessed as the cache table no longer exists.

Description

Additionally the implementation does not match the documentation for the method provided by Adapter::flush().

Code snippet

More details

• Apix-cache version: 1.3.4
• Operating System: RHEL 7.5, Windows 10
• PHP Version: 7.2.14, 7.3.14
• etc..