Open jameskirtland3 opened 2 years ago
Is this covered by #531?
Partially- #531 does recognize the limitations. Shouldn't a database caching implementation use the tenant DB instead of central, though?
Hmm that's a fair point, prefixes would make sense with drivers that use a central storage.
Having the cache inside tenant DBs is something I'd need to test though since I think the cache is sometimes used before tenancy is initialized in the request lifecycle, which could make it difficult to grab the cache values from the right DB.
That said, in v4 the request lifecycle will change as well, so I'll tag this as v4
and consider it while working on it 👍🏻
Description
The project should support the database driver as a caching option. The CacheManager forces the use of tags, making the database driver untenable. Instead, as an option, the CacheManager should use the tenant-initialized DB connections instead of relying on tags to separate cached data.
Why this should be added
Given the utility of the database driver for clean session scoping, the caching implementation for this project seems unusually database-averse. I realize it isn't the optimal driver for many caching processes, but it seems in line with the overall intention of the project.
In a database implementation, the use of tags would be unnecessary (since the cache table could be created in each tenant). Access to the data would be separated by tenant. Resources consumed for cache maintenance would be separated by tenant.
In struggling to get other caching implementations to work for my project, I assumed (incorrectly) I could default to the database driver.