Database migrations for mounted LoopBack 3 Models

[nabdelgadir]

Description / Steps to reproduce / Feature proposal

When mounting a LoopBack 3 application in a LoopBack 4 project using Lb3AppBooterComponent, running npm run migrate will not migrate the LoopBack 3 application's models.

Current Behaviour

By running npm run migrate, LoopBack 3 models are not migrated.

Expected Behaviour

By running npm run migrate, LoopBack 3 models are migrated in addition to LoopBack 4 models.

Acceptance Criteria

• Use a non-in-memory datasource (e.g. MySQL, MongoDB) and run npm run migrate on a mounted application that has both LoopBack 3 and LoopBack 4 models. Make sure both LoopBack 3 and LoopBack 4 models are migrated properly.
  • currently it discovers all LB4 datasources in global LB4 context. since the LB3 app is bound to the context as a whole, you can access all the datasource objects that belong to it by doing lb3App.datasources

[dhmlau]

@nabdelgadir, could you please add acceptance criteria? Thanks!

[bajtos]

Cross-posting from slack.

Take a look at how migrate calls app.migrateSchema and how is the latter implemented in https://github.com/strongloop/loopback-next/blob/7bf6f12f1da721a78071904fa02252577f4d1cba/packages/repository/src/mixins/repository.mixin.ts#L194-L219:

It's iterating over all known datasources and calls ds.automigrate or ds.autoupdate (all known datasources = all datasources bound to the LB4 app).

To migrate LB3 models, we need to execute automigrate/autoupdate also for datasources in the LB3 app.

I see two options how to approach this problem:

1. Modify Lb3AppBooter.load to bind all LB3 datasources into LB4 app context (via app.bind, I don't think we can rely on app.dataSource being added via RepositoryMixin). That way migrateSchema will find both LB4 and LB3 dataSource and migrate them all. The difficult part is how to choose the binding key for LB3 datasources to avoid clashes with datasources defined from LB4. Perhaps it's enough to add a prefix, e.g. db -> datasources.lb3-db? IDK 🤷‍♂
2. Modify Lb3AppBooter.load to bind the booted LB3 app in the context. Modify the migration (I am not sure where exactly) to obtain the LB3 app from the context, iterate over all datasources and for each DS call autoupdate or automigrate.

The first option looks less complex and easier to implement to me.