Custom repository collection/table name

[JesusTheHun]

Currently the name of the collection is specified in the model, through the setting property of the model decorator.

I have two repositories, one storing the current version of the data, the other storing all versions of the data. Right now when I use the create method from those repo, they try to save into the same collection, creating errors.

I would like to store the model in different collections.

Also see this issue, probably code related.

[bajtos]

IIUC, you have one model used with two repository classes and you would like to control the collection/table name in the repository, overwriting any default value provided by the model. Is that correct?

[JesusTheHun]

That is correct. The repository should therefore hold the collection name instead of the model to avoid any ambiguity IMHO.

[bajtos]

That is correct. The repository should therefore hold the collection name instead of the model to avoid any ambiguity IMHO.

I would like to propose a different solution:

• Keep using the model name as the default collection/table name. This is what most people need.
• Allow the repository to overwrite that collection/table name. For example, we can introduce a protected method in DefaultCrudRepository that can be overwritten by subclassed repositories. We can also leverage the recently introduced @config decorator to allow the developer to change the collection/table name without having to create custom repository subclasses. I think the @config based option would be better.

@raymondfeng thoughts?

@JesusTheHun would you like to contribute this improvement yourself? See Contributing code and Submitting a pull request to LoopBack 4 to get started.

[JesusTheHun]

Pre-post : I'm a bit tilted today, sorry if I'm a bit rude :/

IMHO having the model to carry the collection name is bad. I know it's widespread but I think it is bad in several ways :

• On the semantic point it makes no sense, it makes the atomic unit decide where it belongs
• Therefore you cannot use the model in several collections
• It cultivate the idea that the model is where the decisions are made despite the fact it only represents data
• Which enforce a bad patterns to add business logic to models, especially in lifecycle which will come in later releases of LB4.

Since we reached GA, I can't ask your a breaking change. Your first solution introduces confusion imho. The second one seems ok to me.

I'm willing to produce a PR for this. Do you have a gitter for contributers ?

[bajtos]

I think I see your point. To me, this seems like a classic trade-off between making things easier to use (compute the table name from the model name) and more robust (require the repository to provide the table name).

In my proposal, the first item is about preserving backwards compatibility for existing users - this is what we already have implemented today. The second point is about enabling your use case, I am envisioning it as an incremental addition (a backwards-compatible feature).

I'm willing to produce a PR for this. Do you have a gitter for contributers ?

Lovely! Let me know how can I help you.

We are not very active on Gitter, but I'll try to be there more often in the next days. Let's meet here: https://gitter.im/strongloop/loopback-next

[MattiaPrimavera]

Hello ! Can I be assigned to this one ?