mirror of
https://github.com/archtechx/tenancy.git
synced 2026-08-06 03:54:04 +00:00
Automatic multi-tenancy for Laravel. No code changes needed.
https://tenancyforlaravel.com
ecf031237d
`globalCache` should always use the central connection, but when using a
`database`-driver cache store with `DatabaseTenancyBootstrapper`, it
does not (with the exception of `DatabaseCacheBootstrapper`, explained
below).
`globalCache` creates a fresh `CacheManager` each time it's resolved
(it's a `bind`, not a `singleton`). A freshly-created manager builds its
database stores using the current default DB connection. When
`DatabaseTenancyBootstrapper` is active, that default is `tenant`. So
`globalCache` in tenant context points at the tenant DB. Specifically,
`CachedTenantResolver` stores cached tenant lookups via `globalCache`.
When a domain is deleted in tenant context, the invalidation logic calls
`globalCache->forget(...)`, but that hits the tenant DB, while the
resolver cache entry is in the central DB. `globalCache->forget(...)`
doesn't actually do anything in that case.
With `DatabaseCacheBootstrapper`, this is already handled. `globalCache`
is always central because it sets
`TenancyServiceProvider::$adjustCacheManagerUsing` to a callback that
explicitly restores the central connection on `globalCache`'s stores.
To fix this, after constructing the fresh CacheManager in the
globalCache binding, explicitly set the connection of every
database-driver store to its configured connection value, **falling back
to central_connection** when the config value is null (null value =
inherits whatever the current default DB connection is).
This is sufficient for `CacheTenancyBootstrapper` and any other
bootstrapper that doesn't explicitly set the store's DB connection. For
`DatabaseCacheBootstrapper` specifically, this alone is not enough since
it explicitly sets the store's config connection to 'tenant'. That's why
DatabaseCacheBootstrapper's `$adjustCacheManagerUsing` callback runs
after and overrides those stores back to the original (central)
connection.
> In short: `makeDatabaseCacheStoresCentral()` handles stores with a
`null` connection config (falls back to central).
`$adjustCacheManagerUsing` handles the `DatabaseCacheBootstrapper` case
where the config is explicitly set to 'tenant'.
Added datasets that use the database cache store +
CacheTenancyBootstrapper to the relevant tests (globalCache and
invalidation) to test regression
(
|
||
|---|---|---|
| .github | ||
| art | ||
| assets | ||
| doctum | ||
| extensions | ||
| src | ||
| tests | ||
| typedefs | ||
| .gitattributes | ||
| .gitignore | ||
| .nvim.lua | ||
| .php-cs-fixer.php | ||
| CLAUDE.md | ||
| composer.json | ||
| CONTRIBUTING.md | ||
| docker-compose-m1.override.yml | ||
| docker-compose.yml | ||
| Dockerfile | ||
| DONATIONS.md | ||
| INTERNAL.md | ||
| LICENSE | ||
| phpstan.neon | ||
| phpunit.xml | ||
| README.md | ||
| static_properties.nu | ||
| SUPPORT.md | ||
| t | ||
| test | ||
Tenancy for Laravel — stancl/tenancy
Automatic multi-tenancy for your Laravel app.
You won't have to change a thing in your application's code.
- ✔️ No model traits to change database connection
- ✔️ No replacing of Laravel classes (
Cache,Storage, ...) with tenancy-aware classes - ✔️ Built-in tenant identification based on hostname (including second level domains)
Documentation
Documentation can be found here: https://v4.tenancyforlaravel.com
Need help?
Credits
- Package created by Samuel Štancl
- Design help & current logo by Florian Karsten