Unregister runtime artifacts

[bajtos]

When discovering & defining models at run-time (see #2484), it's often important to allow applications to remove artifacts that are no longer used.

In LoopBack 3.x, we provide the following API:

app.deleteModelByName(modelName);

The situation is more complex in LB4, because there are multiple artifacts involved in exposing a data table/collection via REST API:

• Model
• Repository or Service proxy
• Controller

Acceptance criteria

• Application-level API for removing the following artifacts:

  • [ ] Model class
  • [ ] Repository class
  • [ ] Service proxy class
  • [ ] Controller class
  • [ ] DataSource class

  This should include artifacts created automatically by the infrastructure implemented in #2036, #2481, #2483 and possibly other related stories.

• [ ] A stress-test application that can be executed in a memory profiler to verify that no memory is leaked when an artifact is unregistered. The application should implement define+unregister scenarios to cover all different artifact types we support.

• [ ] Should have: an automated test invoked as part of npm test that will run the stress-test application created above in a memory profiler and verify that we are not leaking any memory. Alternatively, verify this fact manually and create a follow-up story to implement an automated check.

[marioestradarosa]

like a garbage collector?.

• in this case datasource classes that connects to the database, do they close their connections once unregistered
• Could you specify unregister ?
  unbind it?

[jannyHou]

Tip: After removing the artifact, make sure the extension point also remove it from cache/rebuild the cache

e.g. Routing table watches the view of controller, make sure it refresh the cache when controller goes.

Suggestion: The scope of this story is too big, we can have a spike for all artifacts and figure out the scope of unregistering them.

[bajtos]

@marioestradarosa

like a garbage collector

We need to delete all references to the artifact we want to remove, so that the garbage collector can reclaim the memory used by that artifact.

in this case datasource classes that connects to the database, do they close their connections once unregistered

Yes, they should close their connections as part of the unregistering workflow.

Could you specify unregister ? unbind it?

I think that's something we need to find out, probably in a spike story.

[emonddr]

This should leverage the lifecycle support mentioned in : https://github.com/strongloop/loopback-next/pull/1928

[dhmlau]

Created https://github.com/strongloop/loopback-next/issues/2619 for the spike.

[stale[bot]]

This issue has been marked stale because it has not seen activity within six months. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository. This issue will be closed within 30 days of being stale.

[stale[bot]]

This issue has been marked stale because it has not seen activity within six months. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository. This issue will be closed within 30 days of being stale.

[stale[bot]]

This issue has been closed due to continued inactivity. Thank you for your understanding. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository.