Repository navigation
LiveQuery fields does not work as expected #8027
Description
New Issue Checklist
- I am not disclosing a vulnerability.
- I am not just asking a question.
- I have searched through existing issues.
- I can reproduce the issue with the latest version of Parse Server.
Issue Description
According to the LiveQuery protocol, the fields parameter can be passed to only listen to updates on certain fields. However, this functions more like "select", where the payload only includes those keys, even if they haven't been updated.
Suppose the ParseObject Player contains three fields name, id and age. If you are only interested in the change of the name field, you can set query.fields to [name]
Steps to reproduce
Create a subscription using the fields parameter, update any other key.
Actual Outcome
Live query is triggered
Expected Outcome
Live query should only trigger if the fields are updated (or new).
Here is an example of a failing test. No matter how many times an object save is called, the spy should only be called if the fields are selected.
it('can handle live query with fields', async () => {
await reconfigureServer({
liveQuery: {
classNames: ['Test'],
},
startLiveQueryServer: true,
});
const query = new Parse.Query('Test');
query.select('yolo');
const subscription = await query.subscribe();
const spy = {
create(obj) {
if (!obj.get('yolo')) {
fail('create should not have been called')
}
},
update(object, original) {
if (object.get('yolo') === original.get('yolo')) {
fail('create should not have been called')
}
}
}
const createSpy = spyOn(spy, 'create').and.callThrough()
const updateSpy = spyOn(spy, 'update').and.callThrough()
subscription.on('create', spy.create);
subscription.on('update', spy.update);
const obj = new Parse.Object('Test');
obj.set('foo', 'bar');
await obj.save();
obj.set('foo', 'xyz');
obj.set('yolo', 'xyz');
await obj.save();
const obj2 = new Parse.Object('Test');
obj2.set('foo', 'bar');
obj2.set('yolo', 'bar');
await obj2.save();
obj2.set('foo','bart');
await obj2.save();
await new Promise(resolve => setTimeout(resolve, 2000));
expect(createSpy).toHaveBeenCalledTimes(1);
expect(updateSpy).toHaveBeenCalledTimes(1);
})Environment
Server
- Parse Server version:
5.3 - Operating system:
macos - Local or remote host (AWS, Azure, Google Cloud, Heroku, Digital Ocean, etc):
local
Database
- System (MongoDB or Postgres):
mongo - Database version:
5.1 - Local or remote host (MongoDB Atlas, mLab, AWS, Azure, Google Cloud, etc):
local
Client
- SDK (iOS, Android, JavaScript, PHP, Unity, etc):
JS - SDK version:
alpha
Activity
parse-github-assistant commentedon Jun 7, 2022
Thanks for opening this issue!
mtrezza commentedon Jun 8, 2022
I think the common interpretation is that LiveQuery should only trigger for the fields set, but this paragraph can be ambiguous, it's missing a clear description of the functionality. Does it more explicitly mention that LiveQuery only triggers for these fields when
fieldsis set?The parameter name is also not well chosen - "fields" does not imply any functionality.
If we want to avoid making this a breaking change, we may use this opportunity to deprecate the
fieldsparam and add a better named paramtriggerFields(or similar) with the new behavior.dblythy commentedon Jun 8, 2022
The full paragraph is here https://github.com/parse-community/parse-server/wiki/Parse-LiveQuery-Protocol-Specification#subscribe-message
I assume that the functionality of "if you are only interested in the change of the name field" is different to the existing functionality of
select. I think creating a param triggerFields and updating the spec accordingly is a good suggestion. Perhaps in the future we could also rename the paramfieldstoselectdblythy commentedon Jun 8, 2022
Actually what do you think of:
query.whereChanged(...keys)query.changed(...)query.triggerFields(...)query.listen(...)query.restrict(...)query.selected(...)query.alter(...)mtrezza commentedon Jun 10, 2022
I changed this from bug to feature, since the PR also seems to be a feature PR, if I got this right?
That's a clever suggestion; but if
fieldscurrently behaves likeselectthen why do we maintainfieldsat all? If the docs currently imply thatfieldsbehaves like a combination ofselectandtriggerFields, then this PR doesn't correct this bug / ambiguity if we leavefieldsas is. On the other hand we also don't want an unnecessary breaking change to fix this.Maybe a clean approach to address the whole issue in a single PR:
fieldswith a changelog comment: "docs are ambiguous, so we phase this out; useselectand/or the newtriggerFieldsto achieve desired behavior"triggerFieldsmtrezza commentedon Jun 10, 2022
You mean as method name instead of
triggerFields? Yes,triggerFieldssounds unnecessarily complex (2 words) - a single word would be better, and it should be a verb instead of a noun.listenorwatchsounds intuitive to me.cbaker6 commentedon Jul 4, 2022
It looks like the
fieldsisn't implemented in LiveQuery for the Objective-C and Android SDK's when I looked through the repos. This is also confirmed in parse-community/ParseLiveQuery-Android#18. I wonder if the released spec was slightly different than the one that was used internally, or if it was just implemented slightly differently after it was made.dblythy commentedon Jan 15, 2023
@cbaker6 I'm thinking that too. Perhaps the spec was built before the feature was built, and it ended up behaving the same as
select. So I suppose this issue is just to update the spec, and then introduce the new featurelisten.cbaker6 commentedon Jan 15, 2023
I believe this comment also supports what you mentioned about fields: parse-community/Parse-SDK-JS#518 (comment)
dblythy commentedon Jan 16, 2023
@mtrezza could you please update the spec:
https://github.com/parse-community/parse-server/wiki/Parse-LiveQuery-Protocol-Specification#subscribe-message
mtrezza commentedon Jan 16, 2023
Sure, do you have a suggestion I can copy/paste?
Interesting this is a GH wiki. Do we need to update anything in the docs as well?