[Laravel] Multi-tenancy support

[cay89]

Description
I would like to use API Platform alongside the Tenancy package. The concept behind Tenancy is simple. There are two types of databases (applications):

• A central database, which stores the list of all tenants (along with other non-tenant-dependent data).
• Multiple tenant databases, where tenant-specific data is stored.

Based on the request, we determine which database should be used for tenant-specific models. And here lies the problem: API Platform only recognizes the structure of the central database at startup and caches the model attributes. As a result, it cannot find the attributes for tenant models.

It seems to work only if the tenant database is a subset of the central database. This means I need to generate all tenant tables in the central database as well and then switch to the tenant database at request time. However, this feels more like a workaround rather than an ideal solution.

[soyuka]

You should build a bridge for tenancy I guess? The metadata for properties / relations is at EloquentPropertyMetadataFactory, then you would maybe need to adapt the data providers/processors for example ItemProvider (but also CollectionProvider, PersistProcessor, RemoveProcessor). We can provide commercial support at Les-Tilleuls.coop if needed.

[cay89]

The problem may be complex, and I don't have in-depth knowledge of the API Platform, so I wouldn’t spend time investigating it. However, I have traced the cause of the issue to ModelMetadata::getAttributes(). It always returns an empty collection from the cache for tenant models. I tried to disable this caching mechanism, which solved the problem with the attributes, but other issues remained, so I gave up... It's not that easy.

[soyuka]

no it's not that easy, you can always override the metadata factory with your own class for tenants but it looks like we should have a cache for tenants and one for models no? Also the ModelMetadata with Eloquent does queries on the database to get the properties and their types therefore I'd recommend to cache it.

[cay89]

Yes, the ideal solution might be to parse both the central and tenant database structures and cache them. However, this is complicated by the fact that the tenant database is only created when a tenant is registered; until then, it exists only in the migration.

Another issue is that I'm not sure how the other components behave. For example, the ID generation (JSON:API format) is also broken, and who knows what else it might affect...