search

archtechx / tenancy

Automatic multi-tenancy for Laravel. No code changes needed.
https://tenancyforlaravel.com
MIT License
3.55k stars 424 forks source link

Introduce database driver support for caching. #852

Open jameskirtland3 opened 2 years ago

jameskirtland3 commented 2 years ago

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.

stancl commented 2 years ago

Is this covered by #531?

jameskirtland3 commented 2 years ago

Partially- #531 does recognize the limitations. Shouldn't a database caching implementation use the tenant DB instead of central, though?

stancl commented 2 years ago

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 👍🏻