Thanks, looking forward to it.
Most probably we’ll include this example in the collection at GitHub - jmix-framework/jmix-samples-2: Examples of solving typical problems in Jmix applications.
Hi,
We have changed the project a little bit as folowing:
- remove tenant field from user entity.
- created many to many relation user<->tenant.
- on user screen posibility to add more than one tenant to which it has rights to see.
- after login screen another screen will appear where you can choose tenant database and where it changes the current database with method you provided.
Here it is the modified version:
https://github.com/sorinfederiga/multidbmt
It works as expected but here are some of the problems I think we have to deal with later and all of them are related :
1.You cannot set the rights on screens separatly by tenant database, only by all of them. I suppose all the rights works the same so we have to make another layer of managining user rights separately. I am not sure if this can be done other than by doing in a inhouse solution.
2.This one is a little bit more tricky as on search box if you save one filter it will remain on all databases. This one it will raise some problems as it mess together different filters that are not suitable from one database tenant to another. I am not sure how it can be done yet.
3. Same is on reports but you can use directly with jasper and do it custom without the jmix addon so this is not so big deal.
What do you think ?
Regards Camil Ghircoias
Hi Camil,
All these issues stem from the fact that entities used by these features (ResourcePolicyEntity, ResourceRoleEntity, FilterConfiguration, Report and so on) are located in the main data store, which is shared. And there is no way to put them in the additional one, which is tenant-specific. So all configuration data is now shared between tenants.
I have an idea to rework the application in such a way that the Main Data Store will become tenant-specific, and an additional shared data store will contain users and tenants. So all built-in configuration entities will be tenant-specific. And if you need a shared entity, you will create it in the additional data store.
Is there any potential issue you foresee with this solution?
Regards,
Konstantin
I beleive this would be the right solution.
Users and tenants in one shared database and the rest database specific. That’s how i deal with specific database now in our winform app. One database for users and some general configuration like rights for one tenant database or another - and the rest like reports, rights on forms and menus all are set in specific database.
If you can make it this way it will solve the tenant problems.
Done. Now the main data store is used for tenant data and the additional shared one stores the lists of users and tenants.
Looking forward to your review and comments!
Regards,
Konstantin
Hi,
I’ve run the app and from what i saw it looks good.
Flow ui data is stored in tenant1,2,3 database not in main database. That is perfect.
Users are stored in shared database.
What method did you used to change where user data like flowui is saved ( from main database in specific tenant database 1,2,3 ) ?
Will do some more tests after the Easter vacation but things looks good so far.
Regards,
Camil
Interesting solution. I have a question, @krivopustov if I wanted to share the information of any table should be marked as @Store(name = "shared") to be used by all tenants?
Another thing, how would REST services work?
Nothing special. All standard Jmix subsystems (the core modules and add-ons) store data in the main data store. So as soon as it became tenant-specific (with the help of RoutingDatasource), the Flow UI settings and filters are now stored in tenant databases.
Yes. Then the entity will be stored in the additional data store shared between tenants.
Generic REST won’t work with tenant databases, all requests will go to the default main database. The proper handling of REST requests needs further R&D. We’ll address it later.
1 Like