Related model shared = false vs. REST exposure

[fabien]

It seems that Model.setup doesn't take into account when a model is not shared - the REST API endpoints are created regardless. Also, setting the generated relation method to shared = false has no effect (this is the method outlined in the docs):

Project.prototype['__create__history'].shared = false;

[raymondfeng]

Do you expect Model.setup() to skip the steps for remoting if shared is false? A typical flow is to configure the model first before calling app.model(MyModel). I would argue it's fine to build the remoting metadata/methods regardless.

For 'Project.prototype['__create__history'].shared = false;', do you see the endpoint in the API explorer? Can you still invoke it? I wonder if you set the flag too late before REST routes are built? I think we should have a method to remove it from remoting after the fact.

[fabien]

Hi @raymondfeng - it might be the case that I'm setting the flag too late. Being able to selectively remove methods from REST exposure would certainly be helpful.

How would you recommend 'registering' models, so they're available from app.loopback.getModel(), yet are not exposed? I find myself using getModel in a few places, even for 'embedded' models, and I like being able to have a unified way to reach them vs. using app.models[modelName] directly.

[bajtos]

How would you recommend 'registering' models, so they're available from app.loopback.getModel(), yet are not exposed? I find myself using getModel in a few places, even for 'embedded' models, and I like being able to have a unified way to reach them vs. using app.models[modelName] directly.

Both app.loopback.getModel(name) and app.models[name] are valid way of accessing the model. The first one is relying on a global static registry, which is something we would like to remove in favour of app.models[name] in the future.

Whenever you call loopback.createModel or Model.extend, the model is registered in the global static registry and is available via loopback.getModel(name). Which means you don't have to register your models if you are accessing them via loopback.getModel.

The method app.model(model) has two purposes:

• modify the configuration of an existing model - attach to a datasource, add relations, etc.
• register the model in app.models

Here is my question: How do you setup your application models? Do you use loopback-boot or do you have your own bootstrapper?

[fabien]

@bajtos thanks for the clarification, that makes sense. I am still on the deprecated loopback-boot setup (the one where app is passed in to the model's module), but I'm hoping to switch over my code-base soon. I prefer to declare 'embedded' models in code only, using a memory datasource (as a convenience, items are never stored there).

It would be nice to have 'one-off' models from time to time, not actually registered anywhere. Is that possible?

[bajtos]

Thanks for the explanation.

It would be nice to have 'one-off' models from time to time, not actually registered anywhere. Is that possible?

Not at the moment.

[raymondfeng]

You can have the one-off models if you use juggler apis, for example:

var modelBuider = new ModelBuilder();
modelBuilder.define(...);

var dataSource = new DataSource(name, settings, modelBuilder);