-
Notifications
You must be signed in to change notification settings - Fork 4
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
fix: added top level property entityTypes #95
fix: added top level property entityTypes #95
Conversation
…missing-top-level-property-entitytypes
…ttps://github.com/cap-js/ORD into fix/69-add-missing-top-level-property-entitytypes
…missing-top-level-property-entitytypes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
generally looks good, please fix the bug mentioned
@zongqichen @swennemers @Fannon : As I've already informed you, if you run the service(in terminal, on path plugins/ORD/xmpl |
This is the reason why I kept this PR to be |
…ttps://github.com/cap-js/ORD into fix/69-add-missing-top-level-property-entitytypes
…missing-top-level-property-entitytypes
if (!SEM_VERSION_REGEX.test(version)) { | ||
Logger.warn(`Entity version "${version}" is not a valid semantic version.`); | ||
} | ||
return version; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to take care of this logic here, if version is not a valid semantic version, we should not return this invalid version, it will be failed by the validator. Instead, maybe return the default value like 1.0.0. I would expect logger level to error.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The default version is not an option. Maybe we should throw an exception in case of non-valid version?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think so, at least we should not provide invalid value. However, I assume this case is really rare in production environment, since we have validator protect us.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you look at the line above the if (!SEM_VER....)) {
, you can see the comment: TODO: version can be stated/overwritten by annotation
Simon told me to keep it that way until we clarify how the version should be set by the model/app-owners.
To his opinion, the right way would be to use an annotation, but he told me to keep it this way for now.
Therefore, I would keep the logger(and not throwing the exception) for now until we have the final statement about the version.
All reported findings are addressed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
No description provided.