Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Models with different cases are mapped to the same file #132

Closed
raymondfeng opened this issue Sep 4, 2014 · 11 comments
Closed

Models with different cases are mapped to the same file #132

raymondfeng opened this issue Sep 4, 2014 · 11 comments
Assignees

Comments

@raymondfeng
Copy link
Member

We can define models as Pet and pet. The runtime can handle that and treat them as different models. But the workspace maps both of them to pet.json. As a result, we lost one of two model definitions.

I understand the file mapping is designed to support operating system such as Mac or Windows which has case-insensitive file names by default.

Should we make model names case insensitive too?

@bajtos
Copy link
Member

bajtos commented Sep 6, 2014

Here is my idea how to address this issue:

  • Add a new property ModelDefinition.fileName, with the default value computed from the model name
  • Modify ModelDefinition.getPath to use this new property
  • Add a validation to enforce unique fileName within each facet

Should we make model names case insensitive too?

Not until we resolve strongloop/loopback#397, as the current workaround relies on case-sensitive model names. Once we have a proper solution, I am all for making model names case insensitive.

@ritch
Copy link
Member

ritch commented Sep 9, 2014

+1 for ModelDefinition.fileName.

@raymondfeng
Copy link
Member Author

I had the impression that we already have the configFile property internally?

@bajtos
Copy link
Member

bajtos commented Sep 10, 2014

configFile is a computed internal property, it includes facet path, etc. The API consumers must not depend on such details. That's why I want to add a fileName property that represents the last path part only, which is exactly what API consumers are interested in.

@ritch
Copy link
Member

ritch commented Sep 11, 2014

We might also be able to add ensureUnique('fileName', {within: 'facet'}) (forgot the exact syntax)...

@bajtos
Copy link
Member

bajtos commented Sep 12, 2014

We might also be able to add ensureUnique('fileName', {within: 'facet'}) (forgot the exact syntax)...

👍

@bajtos
Copy link
Member

bajtos commented Sep 30, 2014

On second though, are all these auto-computed properties worth the effort? Also the solution proposed here creates more work for workspace consumers, as they have to be aware of the new fileName property and implement some mechanism for providing a custom file name when the auto-generated one is not unique.

What if we implemented strongloop/loopback#397 first and then added validation that the model name must be unique within the facet, case-insensitively?

@ritch @raymondfeng

@bajtos
Copy link
Member

bajtos commented Oct 2, 2014

@ritch @raymondfeng ping, what's your opinion on the comment above?

@bajtos
Copy link
Member

bajtos commented Jan 22, 2015

I am proposing to implement a validation rule that the model name must me unique case-insensitively within the fact. It is the easiest possible solution to fix the problem and it will not require any extra work in downstream projects like Arc and generator-loopback.

@stale
Copy link

stale bot commented Aug 23, 2017

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot closed this as completed Sep 6, 2017
@stale
Copy link

stale bot commented Sep 6, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

10 participants