Closed Salketer closed 1 year ago
For the above use case, I would need more understanding of how you are using it through CLI and how you are using cron. For the second question it's not binding in the application context it is binding in Request Context so if there are two concurrent requests they will have different contexts.
Hello, you are right for point 2 we misunderstood the code.
As for the migrations we found a way to change the context during migrations so this works now, we cycle through every known tenant and run the migration for each.
As for the CLI/Cron, we finally went with simply curl'ing our way through, this way the host picks the correct tenant.
Sorry for the delay in reply, as I understood this issue can be closed, or If you want any help just let me know. or any feature request for any special scenario handling.
Hello, we are currently implementing this for our app and it works fine.
The only problem we have is for crons and migrations. We currently use loopback's schema migration but this is ran from CLI, crons are using the cron component supplied by the loopback team. Both of those run at the Application Context level so we do not have a means to determine the tenant. Even worse, we'd need to run the scripts for each and every known tenant.
How would you suggest we get through this?
Also, we have not ran the tests yet but from my understanding, this component changes the datasource binding value on the application context. If we have 2 concurrent requests for different tenants wouldn't the first request end up with the database from the second request?
Thanks