WireCache adapters/backend

[pine3ree]

WireCache adapters

I believe it would be useful to have WireCache being able to save into a different backend other than the database [ I am now thinking about simple (json/php-serialize) cache files like MarkupCache does but memcache/redis could be then implemented] so that one can choose where to save/fetch cached data. kind regards

[teppokoivula]

but memcache/redis could be then implemented

Having an easy option to use Redis with WireCache would be a welcome addition :)

WireCache is currently pretty tightly coupled with SQL database, but actual implementation could be moved to another class, or perhaps it would make sense to support "WireCache modules" similar to WireMail modules, so that one could easily install another one (such as WireCacheRedis) that would then automatically replace built-in WireCache.

[pine3ree]

Right, @teppokoivula... The api of WireCache is very intuitive, that's the reason why having this extra functionality would be very useful. To achieve it either we transform it to an interface with different implementations based for different backends or we add a ctor "backend" parameter (instance, fqcn, string identifier) for the backend (defaulting for BC to the database adapter) and forward all data manipulation methods to the internal backend instance. The 1st option would be more formal, but the 2nd could be implemented more easily into pw. Modules like WIreMail modules would be another (maybe "the" pw-way) alternative...but in that case you'll need a base class with a working implementation (e.g the current database implementation) and then override all the data-related methods in the extension (base-class descendant) module. Best regards...

[teppokoivula]

Modules like WIreMail modules would be another (maybe "the" pw-way) alternative...

Exactly. And the way I see it, this is is a strong argument in itself. WireMail modules are, in my opinion, a good example: there are some really good options out there, they're easy to develop (for anyone familiar with PW modules), and using them is just about as simple as it gets :)

I don't necessarily see a lot of value in splitting the code into multiple "layers", particularly if it adds complexity — which, in turn, would be likely to reduce interest in building on it, and/or using solutions built on it. What Ryan has done with WireMail makes sense to me: WireMailInterface defines common requirements, and the core WireMail implementation is both a base class to build upon, and a working basic implementation.

This sounds like a very neat concept, though honestly speaking I would assume that most folks will still prefer the MySQL version of WireCache, both now and in the future. File based cache could be a strong contender, if it was available as an alternative. I may be wrong, of course, but I'd assume that relatively small portion of users will have Redis or Memcached ready to use, or even care that much as long as things just work :)

[pine3ree]

@teppokoivula I agree on most of your arguments. The only idea I have doubts about is the default implementation. I believe for instance that in the WireMail case the base class should have abstract methods for ad-hoc implementations (or simply be abstract class w/o implementing them) and an internal WireMailPhpMail module should be provided as a default. A non otherwise configured mailer instance would then load the default php-mail implementation. This would provide a cleaner separation between the interface and the implementation. Of course WireMail is a simple case with one ovverriden method.

I obviously prefer memcache(d) to file-caching, but as you said it may not be available in shared hosting environments. Some providers also limits MySQL server communication by counting the issued queries (not always the load generated from them)...so avoiding as many sql-queries as possibile helps even if just using filesystem based caching. Furthermore, php also caches loaded files when compiling.

...anyway...independently on how this can be done, I believe it would be a useful feature. :-) cheers!

kind regards

[ryancramerdesign]

Sounds worthwhile to me. Though WireCache is part of the boot process, before modules are even loaded, and it manages caches for the Modules class that is used during boot. So it would have unique considerations and might need to be overridden from something defined in /site/config.php rather than an autoloaded module. Maybe something like the current $config->sessionAllow that can be a callable.

Most of the code in the WireCache class is cache related logic rather than database code, and that logic would be the same regardless of where the caches are stored. So if there were to be an interface for modules it would be a WireCacheStorage interface rather than one that replaces WireCache. Basically the same concept as the WireSessionHandler interface. The interface would probably need these methods: get, getInfo, getMatch, save, delete, deleteAll, expireAll, maintenance. It would be pretty simple to move the current DB cache logic into a class implementing that interface, and having it in a separate class would make it possible to replace with another (redis, memcache, etc.)

[eydun]

I guess this request has been solved?

https://processwire.com/talk/topic/28521-weekly-update-–-19-may-2023/