bug(cli): cli does not respect custom relation getter name

[derdeka]

Steps to reproduce

Generating hasMany relation between News and NewsFile object. Naming it files instead of the default newsFiles:

@loopback/cli@1.26.0

Current Behavior

The custom name files is used in the model, but not in the repository:

Expected Behavior

Expecting consistent naming across model and repository.

[achrinza]

Correct me if I'm wrong but I believe this is expected behaviour. The CLI prompts for setting the property name (not the relation name), which in this case works fine.

[derdeka]

@achrinza if this is the expected behavior, maybe there should be another prompt for customizing the naming in the repository?

[achrinza]

Just curious, what’s the use case for custom relation names?

…

________________________________ From: derdeka <notifications@github.com> Sent: Tuesday, November 26, 2019 5:07:45 PM To: strongloop/loopback-next <loopback-next@noreply.github.com> Cc: Rifa Achrinza <rifa@achrinza.com>; Mention <mention@noreply.github.com> Subject: Re: [strongloop/loopback-next] bug(cli): cli does not respect custom relation getter name (#4209) This email was sent from outside the organization. Please be cautious, the sender may not be who they claim to be. @achrinza<https://github.com/achrinza> if this is the expected behavior, maybe there should be another prompt for customizing the naming in the repository? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#4209>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AF73T6Y6F4V3J7ZGIOCSGG3QVTRODANCNFSM4JRULUAQ>.

[derdeka]

Just curious, what’s the use case for custom relation names?

I have a model inheritance like NewsFile extends BaseFile and ContractFile extends BaseFile to have shared properties and some additional custom properties per subclass - each subclass is storing in it's own relational database table. On the api it's just named files.

[achrinza]

@derdeka Thanks for providing extra info. I think this feature is a possibility (albeit the decision is up to the core maintainers), though there are limitations on using class inheritance that might be important to take note of.

[achrinza]

I've dug into the code and docs and found some inconsistencies:

1. --relationName option is used for setting the property (see here)
2. Internally, the function responsible referred to as a promptRelationName (see here)
3. Internally, the constant storing the prompt message is called PROMPT_MESSAGE_PROPERTY_NAME (see here)
4. Internally, the default FK property generator is called _getDefaultRelationName (see here)
5. The end result is the FK property name being affected and not the relations name.

There seems to be ambiguity on what this prompt is supposed to do.

It doesn't help that the hasMany and hasOne docs also mention that their respective property relation decorators support the name field name which is defined as the name of the relation (which is different from what the CLI references).

[achrinza]

@dhmlau Maybe the core maintainers might want to look into this; if this is expected behaviour

[bajtos]

Expecting consistent naming across model and repository.

+1

I think this is a bug, an oversight on the side of the person implementing lb4 relation command.

@derdeka @achrinza would you like to contribute the fix yourself?