Multi DB support in 1.8?

[friarpat]

Prior to 1.8, a middleware could change which database was to be accessed by the various services by doing something like:

    req.scope.register({manager: asValue(manager)});
    req.scope.cache.clear();
    req.scope = req.scope.createScope() as any;

...passing in the manager that was connected to the desired database.
As of 1.8, this functionality no longer seems to work? I can perform the above steps. I can verify in a "later" middleware that the manager in the DI is indeed pointing to the desired database. I can successfully query for data from that database using the manager from the DI.

...but getting a list of products via store/products always returns data from the default database regardless what value is in the req.scope.

Is there a new way of handling this in 1.8?

Thanks!

[srindom]

Maybe @adrien2p has some inputs on this? :)

@friarpat - out of curiosity, what do you use this "dynamic db control" for?

[friarpat]

Oof! Don't know why I didn't see it before, but in the Medusa dependency documentation I see:

Core services by default have the SINGLETON lifetime. However, some have a different lifetime which is indicated in this table. Custom services, including services in plugins, by default have the SCOPED lifetime, unless defined differently within the custom service.

I'm assuming that's why I'm not getting a new instance of the services when the scope is recreated for the request?
Is the solution to extend all core services and make the lifetime SCOPED?

[friarpat]

Sorry - didn't see your response. I'll take this up with typeorm.

[adrien2p]

no this is not why, I ve used cache clear in order to force the entire container to be re resolved exactly for the singleton issue. So that is why it was working prior medusa 1.8

[friarpat]

uhhh-k. This is a "design out loud" post...but seeing if I'm on the right track or going to cause someone on the team to faint!

Assumption 1: All of those repositories in the DI get recreated on a createScope() call.
Assumption 2: The repositories are using the database loader to get the datasource for the repository when the new scope is created.
Assumption 3: I can override a loader in Medusa.

Provided the above assumptions are valid - grab your air sickness bag...

• Instead of having the database loader ONLY load configuration from medusa-config.js each time it's called, have it load it from the DI as "ActiveDBConfig". ...if that's not present, then load from medusa-config.js
• default config is from the medusa-config
• Set another DI value with "ActiveDBName"
• default to "default"
• Create a DI value that contains a map of DataSourceConnectors.
• Extend the database loader to function similarly to the DataSourceManagerService indicated above. That is, if the "ActiveDBName" is in the DataSourceConnectors - return the datasource. If not, use the "ActiveDBConfig" to create the DataSourceConnector, stash it in the DI's DataSourceConnectors map, then return the datasource.
• The middleware would now register the ActiveDBConfig in case this is a new connection, set the ActiveDBName in the request's copy of the scope, flush the cache, then create the new scope.
• The extended database loader should now either create the new connection and cache it, or, simply return the cached dataSource from the DI as the various repositories are created/instantiated as part of the createScope() call.

Provided you survived the above description - which DI scope would the database loader be using to look for cached dataSources when doing the createScope() call? Wouldn't want to change the "base" DI scoped ActiveDBConfig and ActiveDBName, but would want to share all of the cached dataSources across all "users". Is it enough to make the DataSourceConnectors a SINGLETON, and the other two SCOPED?

[adrien2p]

I think that in fact you would only have to resolve all the repositories and change the manager and queryRunner by assigning the new one from the new datasource. But there might be some risk and i would advise you to wait for typeorm answer or look at typeorm implementation if they don’t come back to you, or use a different multi tenancy approach such as multi schema for example

[CervarlCG]

Hello, did you find a solution for this?

[friarpat]

I did not. I attempted several things…but in the end – at that time, it seemed like Medusa moved away from supporting anything “multi” with their latest version. Our timelines were too short to attempt to sway typeorm for Medusa’s needs. All of this may have changed by now? We had to abandon Medusa and go with a solution that was less desirable. Too bad, as I think there are lots of folks out there that need something like this! From: Jesus Cervantes ***@***.***> Sent: Wednesday, July 5, 2023 9:47 AM To: medusajs/medusa ***@***.***> Cc: friarpat ***@***.***>; Mention ***@***.***> Subject: Re: [medusajs/medusa] Multi DB support in 1.8? (Discussion #3819) Hello, did you find a solution for this? — Reply to this email directly, view it on GitHub <#3819 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADAICAGTM6U4O7OEJJ2FSSDXOV44VANCNFSM6AAAAAAW4GOUVQ> . You are receiving this because you were mentioned. <https://github.com/notifications/beacon/ADAICAHR4KKTEO3QMD7ECEDXOV44VA5CNFSM6AAAAAAW4GOUVSWGG33NNVSW45C7OR4XAZNRIRUXGY3VONZWS33OINXW23LFNZ2KUY3PNVWWK3TUL5UWJTQAMENM2.gif> Message ID: ***@***.*** ***@***.***> >

[octalpixel]

@friarpat what solution have you considered now ?

[vkislichenko]

I'm having similar problems, and I think implementation of an option to "properly" scope modules - would bring solution a bit closer.
I've opened dedicated feature request for it.

for now my plan is to force "scoped" lifetime to all registrations in main container + override (similarly how medusa-extender did it) modules loader to implement "native" cradle usage

[amirping]

I'm willing to find a solution to implement the multi-tenancy design with Medusa, but yeah looks very hard now. it was easier with the extender but it's not here anymore.