Settings with Tenancy for Laravel

[xemedia]

Hi,

i use "Spatie Settings" and "Stancl Tenancy for Laravel".
A separate database is used for each tenant. In the event of a database query, the database of the current tenant is automatically set as the default.

I face the following problem:
The settings for all tenants are taken from the same - the main database. So all tenants have the same settings.

How do I have to adapt the config so that the settings are saved in the tenant database?
I made all migrations and a settings tabe for each tenant exists.

Thanks in adavance.

[rubenvanassche]

Hi @xemedia,

We had the same problem in the project this package was built for. Though we're using our own spatie/multitenancy package I think the setup is the same. Within the config of the package you can set a model that will be used for stroring the settings (https://github.com/spatie/laravel-settings#repostitories). You should in a multi-tenancy setup create your own model which extends from the package model. In this model you can overwrite the connection to the correct database that should be used for the tenant.

[rubenvanassche]

😛

[vanhooff]

IS there any way to refresh repository settings or database connection for tenants and reload its data?

Hi atapatel, can you please show me how you did this?

[atapatel]

@sandervanh How would you like to connect?

[vanhooff]

Thanks for your reply, i replied to the wrong comment. My question is how to set the tenant-connection in the model? I created a model TenantSettingsProperty which extends Spatie\LaravelSettings\Models\SettingsProperty, but having trouble setting the correct connection. Curious how you did it!

[ousid]

Hey @atapatel

I'm facing the same problem, could you show me how you solved your issue?

Thanks!

[rronik]

Hello @rubenvanassche,

I came across a similar problem.

In my application, I use "Spatie Settings" and "Stancl Tenancy for Laravel" (multiple databases) so I created a "settings" table in each of the Tenant's databases. My problem was with caching the settings (using Redis). I needed to prefix the redis key for each Tenant with their UUID. I tried updating the "settings.cache.prefix" in the config file after resolving the Tenant using the solution provided in Stancl Tenancy for Laravel docs.
Since the settings cache prefix is passed as a parameter in the SettingsCache constructor and an instance of this class is initiated when the service provider is registered, which occurs before the Tenant is resolved, overwriting the config file using this method makes no sense. In this case, changes in the config file will not reflect!

The solutions I have thought of are:

1. Change the prefix property from private to public and make it static link to updated class

   • This will enable to use a similar solution as mentioned here with some minor changes:

   Adding the following lines in my AppServiceProvider::boot() method does the trick:

   Event::listen(TenancyBootstrapped::class, function (TenancyBootstrapped $event) {
        SettingsCache::$prefix = 'spatie.settings.cache.tenant.' . $event->tenancy->tenant->id;
    });
   

2. Modifying the resolveCacheKey() method in SettingsCache to get the prefix directly from the config file instead of the prefix property. Since the prefix property is not used elsewhere it can be removed.

   • This enables us to use the solution provided by Stancl (link).

In my opinion, the second solution requires more effort therefore I chose the first one.

I have already forked the repo but I have not opened any Issue ticket or created any PR. Do you think this is necessary?

[rubenvanassche]

Hi @rronik,

I think we want to avoid static properties due to Octane not liking them. So I would accept a PR implementing method 2.

A third solution could be to make SettingsCache scoped (basically a singleton Octane likes) and then provide setter methods on the SettingsCache for the prefix in the closure mentioned in method 1. Would this work in Tenancy? I think it is the most elegant one 😄

[rronik]

Hi @rubenvanassche,

Sorry for the late reply, I tried the solution that you suggested but not all tests passed. Since the second proposed method is still a valid solution and all tests seem to be passing, I can make a PR implementing that method if it's okay with you.
Thank you for your time and effort if you need any more information please let me know.

P.s: I will also attach the output of failed tests when I tried implementing the third solution.

output.txt

[rubenvanassche]

Maybe a fourth method is possible, could we move the code for determining the settings cache key onto the settings object? If we add a static method resolveCacheKey onto the settings object which gets called then you could inject the tenant id over there. This would also solve this problem (#139)

[mybouhssina]

@rronik I encountered the same problem and I ended up adding the package to my composer dont-discover and manually registering the package ServiceProvider after the TenancyInitialized event is fired, I know this is not the right way to do it, but it seems to be working for now:

Events\TenancyInitialized::class => [
                Listeners\BootstrapTenancy::class,
                function() {
                    config(['settings.cache.prefix' => 'tenant' . tenant()->id]);
                    app()->register(LaravelSettingsServiceProvider::class);
                }
            ],

[farisfaikar]

I'm having a weird problem when using the spatie/laravel-settings package and tenancy-for-laravel package where in the settings table, for every column group that has the value of general, the tenant side reads from the central database instead of the tenant database. I'm using multi-database, so this shouldn't be the case.

The weird part is, that tenancy works just fine on every other table and even in the same settings table that's in a different group. What's even weirder is that the data is updated just fine in the tenant database. It's just the read operation that's messed up and it's reading from central instead of tenant. I've reviewed the codes and I can't find any difference between the other setting classes.

This is an old discussion, but I was wondering if you guys have any clues about where the problem may lie. Thank you