Skip to content

Select queries should not erase cached data from unselected fields #409

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

Merged
merged 2 commits into from
May 23, 2017

Conversation

dstarke
Copy link
Contributor

@dstarke dstarke commented Feb 11, 2017

When a query is issued with a select, we know that the object returned will only be part of the truth from the server. The current implementation, on retrieving the results of a query with a select, erases all the information in the shared object except the fields included in the select, which are updated. That's not the best possible estimate of the state of truth on the server.

Ideally, for a query with a select, the cached object should only be updated or erased for the fields involved in the query.

This PR introduces test cases for retrieving previously retrieved objects with a more restrictive select clause in accordance with the above goal, and proposes a code change that fixes the issue and allows these new test cases to pass.

Fixes #371.

@jeveloper
Copy link

Just curious, is anyone going to merge any of those pending pull requests ?

@flovilmart
Copy link
Contributor

@hramos can you get me access here?

@flovilmart
Copy link
Contributor

@dstarke what a beautifully tested PR. I'll jump into it later today

Copy link
Contributor

@flovilmart flovilmart left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dstarke sorry, I've been under the water a bit lately. Just a small recommendation on the code formatting for that PR (spaces mostly). Can you address those?

like

if(hasSubObjectSelect){

should be

if (hasSubObjectSelect) {

@codecov
Copy link

codecov bot commented May 23, 2017

Codecov Report

Merging #409 into master will increase coverage by 0.13%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #409      +/-   ##
==========================================
+ Coverage   84.35%   84.49%   +0.13%     
==========================================
  Files          46       46              
  Lines        3663     3696      +33     
  Branches      835      846      +11     
==========================================
+ Hits         3090     3123      +33     
  Misses        573      573
Impacted Files Coverage Δ
src/ParseQuery.js 95.12% <100%> (+0.54%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2956dec...1ca4407. Read the comment docs.

@codecov
Copy link

codecov bot commented May 23, 2017

Codecov Report

Merging #409 into master will increase coverage by 0.13%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #409      +/-   ##
==========================================
+ Coverage   84.35%   84.49%   +0.13%     
==========================================
  Files          46       46              
  Lines        3663     3696      +33     
  Branches      835      846      +11     
==========================================
+ Hits         3090     3123      +33     
  Misses        573      573
Impacted Files Coverage Δ
src/ParseQuery.js 95.12% <100%> (+0.54%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2956dec...1ca4407. Read the comment docs.

@flovilmart
Copy link
Contributor

Thanks for the fixes! This reminds me I need to setup a linter on that repo as well.

@flovilmart
Copy link
Contributor

@dstarke it seems that this PR has introduced an issue, can you have a look shortly please?

@dstarke
Copy link
Contributor Author

dstarke commented Sep 9, 2017

The tests for ParseQuery do specifically test for that condition, and they pass (I just checked this as well), so I think the problem may be somewhere else. The tests for ParseQuery, though, directly supply the objects returned by queries, since they come from another unit.

I'm trying to figure out how to reproduce it.

@flovilmart
Copy link
Contributor

I didn’t managed to repro either, but I believe @dplewis had a hunch

@dstarke
Copy link
Contributor Author

dstarke commented Sep 9, 2017

I did find some problems with how sub-objects were handled. Added tests and fixes for those problems in the PR I just created. I still can't quite reproduce the issue as described in #475, but this should fix at least one of the issues that is discussed in: parse-community/parse-server#3999.

@flovilmart
Copy link
Contributor

@dstarke thanks for the quick response!

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

Successfully merging this pull request may close these issues.

after select query object overide
4 participants