-
Notifications
You must be signed in to change notification settings - Fork 76
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
Handle missing baseVersion in entity upsert (create and update) case #1209
Conversation
Now this other test is failing... if we are parsing baseVersion in the create context instead of the update context, what should we do? In the offline entity update-as-create case, we kind of wanted to track that baseVersion. In the regular entity case, we don't expect to see a baseVersion with an entity create. We could probably always parse it (return it from
|
688fa02
to
73ad6c4
Compare
This could be reviewed by either @matthew-white or @sadiqkhoja. It could probably be done async but I'm happy to review synchronously with someone too. It shouldn't take too long to talk through it. |
lib/data/entity.js
Outdated
if (update) { | ||
if (!baseVersion) |
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.
Could these two if
s be combined?
if (update && !baseVersion) {
Or since you also have an if
below that's checking isBlank()
, maybe something like this would be possible:
if (isBlank(baseVersion)) {
if (update)
// throw ...
return null;
}
// (No need for an `else`, since `throw` and `return null` both end the function.)
// Check type and parseInt in both create and update case
// ...
return parseInt(entity.system.baseVersion, 10);
Closes getodk/central#727
Thanks for the example test, @sadiqkhoja! I used it to debug and then made a simplified test.
When create and update are both present in an entity, Central first tries to update and then tries to create if the update failed in a certain way.
In this scenario, the update step was failing at the parsing step. The update flag in the entity system data is set to true, but there is no base version, and that causes an error. The code changes how the parsing works a little bit to not use what is written in the entity system data directly, but to use the context of whether it is currently trying to update or create. A similar change was made to the label parsing method.
What has been done to verify that this works as intended?
Why is this the best possible solution? Were any other approaches considered?
How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?
Does this change require updates to the API documentation? If so, please update docs/api.yaml as part of this PR.
Before submitting this PR, please make sure you have:
make test
and confirmed all checks still pass OR confirm CircleCI build passes