-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Mongo Panache Extension] Dynamically select database #14789
Comments
/cc @FroMage, @evanchooly, @loicmathieu |
Yes, dynamic selection of MongoClient / MongoDatabase is not possible at the moment. Having a way to resolve it dynamically, as you proposed with your |
To facilitate the feature integration, we can also imagine a It's just another implementation idea 😃 |
Hi, i was wondering if you could provide a code example on how to implement resolving mongodb database name based on tenant information. I'm currently working on a proof of concept, where having different db is mandatory for each tenant using panache. I'm struggling implementing a solution. Therefore i would be very grateful if you could provide some more information. |
@m4k4veli I managed to implement this kind of multitenancy only with the mongodb client extension, not with panache. |
Many thanks for your effort. This helped me alot, and your solution shows what i expected on how to implement multi-tenancy via mongoclient, at least ss long as panache cannot dynamically select the database. |
Hi ! We encountered the same difficulties, is there any news on this issue ? |
I also have more ideas in mind. Another approach that I wasn't able to reproduce is mongo client name dynamic selection, we need to pass a fixed database for each MongoEntity. So maybe a MongoClientNameResolver could be implemented too, maybe we can follow the same approach of the PR and on processor we can check if there is a MongoClientNameResolver implementation, all the application.properties connections configs should be added to be lazily produced |
IMO, multitenancy should absolutely not be a concern for quarkus/panache. These are ODM concerns and we (well, I ...) really don't want panache to slowly accrete ODM functions when there are functional ODMs out there already. |
@evanchooly I understood your point. So how about do we have at least the capability to dynamically select the database? |
We want MongoDB with Panache to keep it simple, but if we can have some kind (not all kind) of multi-tenancy with low cost it's OK for me. Your proposed PR seems to be simple enhought. @evanchooly I usually agree for advanced features to be for an ODM solution, but multi-tenancy IMHO is not such feature as it is a low level feature to select wich cluster/database/... to use dynamically. |
The PR itself seems reasonably non-invasive though I do agree that it would probably be better to do at the mongo-client level instead. However, we don't really deal with databases there but just the clients themselves so this is probably only really doable inside panache. At a minimum it offloads any "unwanted" complexity to users' code. I left some questions on the PR. |
…of github.com:pedroh-pereira/quarkus into feat/quarkusio#14789-adding-panache-database-resolver
…e-database-resolver
…che-database-resolver MongoDb with Panache: Add multi-tenancy support to MongoDb Panache throught dynamic database selection
Fixed by #29665 |
Description
A few month ago, I've submitted an issue regarding the implemention of multitenancy within quarkus mongo panache extension (see #5183).
It seems that quarkus mongo panache extension now support some kinds of multitenancy implementations like multiple mongo client or database selection through @MongoEntity annotation.
However, it seems not possible to implement multitenancy by using a database by tenant (on the same cluster).
For example :
I managed to implement this scenario only with mongo client extension by :
Does this solution can be considered as "good" ? Or do you recommend another approach ?
Is it possible, today, to have similar feature with mongo panache extension ? Or this require an evolution of it ?
Implementation ideas
I saw that some extensions, like oidc or hibernate, offer the possibility to implement a TenantResolver interface. Having such a possibility to configure the mongo client will likely allow to implement this kind of multitenancy.
The text was updated successfully, but these errors were encountered: