How to skip initial data and trigger only new updates in Firestore Firebase?
up vote
3
down vote
favorite
I've searched everywhere with no luck. I want to query Firestore to get all users WHERE type is admin. Something like:
SELECT * FROM users WHERE type=admin
but only when the property total
is changing. If I'm using:
users.whereEqualTo("type", "admin").addSnapshotListener(new EventListener<QuerySnapshot>() {
@Override
public void onEvent(@Nullable QuerySnapshot snapshots, @Nullable FirebaseFirestoreException e) {
for (DocumentChange dc : snapshots.getDocumentChanges()) {
switch (dc.getType()) {
case ADDED:
//Not trigger
break;
case MODIFIED:
//Trigger
break;
case REMOVED:
//
break;
}
}
}
});
The case ADDED is triggered first time when I query and when the total
is changed case MODIFIED
is triggered again (this is what is want). I want only changes and not the all initial data, I don't need it. How to get it?
Please help me, is the last part of my project. How to skip is case ADDED
?
java android firebase google-cloud-firestore
add a comment |
up vote
3
down vote
favorite
I've searched everywhere with no luck. I want to query Firestore to get all users WHERE type is admin. Something like:
SELECT * FROM users WHERE type=admin
but only when the property total
is changing. If I'm using:
users.whereEqualTo("type", "admin").addSnapshotListener(new EventListener<QuerySnapshot>() {
@Override
public void onEvent(@Nullable QuerySnapshot snapshots, @Nullable FirebaseFirestoreException e) {
for (DocumentChange dc : snapshots.getDocumentChanges()) {
switch (dc.getType()) {
case ADDED:
//Not trigger
break;
case MODIFIED:
//Trigger
break;
case REMOVED:
//
break;
}
}
}
});
The case ADDED is triggered first time when I query and when the total
is changed case MODIFIED
is triggered again (this is what is want). I want only changes and not the all initial data, I don't need it. How to get it?
Please help me, is the last part of my project. How to skip is case ADDED
?
java android firebase google-cloud-firestore
add a comment |
up vote
3
down vote
favorite
up vote
3
down vote
favorite
I've searched everywhere with no luck. I want to query Firestore to get all users WHERE type is admin. Something like:
SELECT * FROM users WHERE type=admin
but only when the property total
is changing. If I'm using:
users.whereEqualTo("type", "admin").addSnapshotListener(new EventListener<QuerySnapshot>() {
@Override
public void onEvent(@Nullable QuerySnapshot snapshots, @Nullable FirebaseFirestoreException e) {
for (DocumentChange dc : snapshots.getDocumentChanges()) {
switch (dc.getType()) {
case ADDED:
//Not trigger
break;
case MODIFIED:
//Trigger
break;
case REMOVED:
//
break;
}
}
}
});
The case ADDED is triggered first time when I query and when the total
is changed case MODIFIED
is triggered again (this is what is want). I want only changes and not the all initial data, I don't need it. How to get it?
Please help me, is the last part of my project. How to skip is case ADDED
?
java android firebase google-cloud-firestore
I've searched everywhere with no luck. I want to query Firestore to get all users WHERE type is admin. Something like:
SELECT * FROM users WHERE type=admin
but only when the property total
is changing. If I'm using:
users.whereEqualTo("type", "admin").addSnapshotListener(new EventListener<QuerySnapshot>() {
@Override
public void onEvent(@Nullable QuerySnapshot snapshots, @Nullable FirebaseFirestoreException e) {
for (DocumentChange dc : snapshots.getDocumentChanges()) {
switch (dc.getType()) {
case ADDED:
//Not trigger
break;
case MODIFIED:
//Trigger
break;
case REMOVED:
//
break;
}
}
}
});
The case ADDED is triggered first time when I query and when the total
is changed case MODIFIED
is triggered again (this is what is want). I want only changes and not the all initial data, I don't need it. How to get it?
Please help me, is the last part of my project. How to skip is case ADDED
?
java android firebase google-cloud-firestore
java android firebase google-cloud-firestore
edited Nov 5 at 14:30
Alex Mamo
37.9k62557
37.9k62557
asked Nov 5 at 14:13
Sky Tracker
184
184
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
4
down vote
accepted
When you are listening for changes in Cloud Firestore for realtime changes, using Firestore Query's addSnapshotListener() method, it:
Starts listening to this query.
Which basically means that first time you attach the listener, you get all documents that correspond to that particular query. Furthermore, everytime a property within a document changes, you are notified according to that change. Obviously, this is happening only if the listener remains active and is not removed.
Unfortunately, Firestore listeners don't work that way, so you cannot skip that "case ADDED". What you can do instead, is to add add under each user object a Date
property (this is how you can add it) and query your database on client, according to this new property, for all documents that have changed since a previous time.
According to Nick Cardoso's comment, for future visitors that might ask why this behaviour happens, is because the reason he mentioned in his comment. I also recommend see Doug Stevenson's answer from this post, for a better understanding.
Thank for the answer, I try your solution.
– Sky Tracker
Nov 5 at 17:49
Ok, keep me posted.
– Alex Mamo
Nov 5 at 18:04
Hi Sky! Have you tried my solution above, does it work?
– Alex Mamo
Nov 6 at 7:44
This answer is incomplete as it misses a big point (the date solves the issue, but doesn't explain why the behaviour happens). The snapshot provides data from the local cache as well as mutations from the remote. So if you only wan't changes (implying this is a repeated query) it's not fetching (and charging for) everything again. It's getting just the mutations as expected, you just have to handle it appropriately.
– Nick Cardoso
Nov 9 at 9:25
1
@NickCardoso Regarding your question, hope that the down-voter will also provide a reason, as you did in my case. Just up-voted because I found your question very helpful and hope you'll find an answer soon.
– Alex Mamo
Nov 9 at 9:48
|
show 1 more comment
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
4
down vote
accepted
When you are listening for changes in Cloud Firestore for realtime changes, using Firestore Query's addSnapshotListener() method, it:
Starts listening to this query.
Which basically means that first time you attach the listener, you get all documents that correspond to that particular query. Furthermore, everytime a property within a document changes, you are notified according to that change. Obviously, this is happening only if the listener remains active and is not removed.
Unfortunately, Firestore listeners don't work that way, so you cannot skip that "case ADDED". What you can do instead, is to add add under each user object a Date
property (this is how you can add it) and query your database on client, according to this new property, for all documents that have changed since a previous time.
According to Nick Cardoso's comment, for future visitors that might ask why this behaviour happens, is because the reason he mentioned in his comment. I also recommend see Doug Stevenson's answer from this post, for a better understanding.
Thank for the answer, I try your solution.
– Sky Tracker
Nov 5 at 17:49
Ok, keep me posted.
– Alex Mamo
Nov 5 at 18:04
Hi Sky! Have you tried my solution above, does it work?
– Alex Mamo
Nov 6 at 7:44
This answer is incomplete as it misses a big point (the date solves the issue, but doesn't explain why the behaviour happens). The snapshot provides data from the local cache as well as mutations from the remote. So if you only wan't changes (implying this is a repeated query) it's not fetching (and charging for) everything again. It's getting just the mutations as expected, you just have to handle it appropriately.
– Nick Cardoso
Nov 9 at 9:25
1
@NickCardoso Regarding your question, hope that the down-voter will also provide a reason, as you did in my case. Just up-voted because I found your question very helpful and hope you'll find an answer soon.
– Alex Mamo
Nov 9 at 9:48
|
show 1 more comment
up vote
4
down vote
accepted
When you are listening for changes in Cloud Firestore for realtime changes, using Firestore Query's addSnapshotListener() method, it:
Starts listening to this query.
Which basically means that first time you attach the listener, you get all documents that correspond to that particular query. Furthermore, everytime a property within a document changes, you are notified according to that change. Obviously, this is happening only if the listener remains active and is not removed.
Unfortunately, Firestore listeners don't work that way, so you cannot skip that "case ADDED". What you can do instead, is to add add under each user object a Date
property (this is how you can add it) and query your database on client, according to this new property, for all documents that have changed since a previous time.
According to Nick Cardoso's comment, for future visitors that might ask why this behaviour happens, is because the reason he mentioned in his comment. I also recommend see Doug Stevenson's answer from this post, for a better understanding.
Thank for the answer, I try your solution.
– Sky Tracker
Nov 5 at 17:49
Ok, keep me posted.
– Alex Mamo
Nov 5 at 18:04
Hi Sky! Have you tried my solution above, does it work?
– Alex Mamo
Nov 6 at 7:44
This answer is incomplete as it misses a big point (the date solves the issue, but doesn't explain why the behaviour happens). The snapshot provides data from the local cache as well as mutations from the remote. So if you only wan't changes (implying this is a repeated query) it's not fetching (and charging for) everything again. It's getting just the mutations as expected, you just have to handle it appropriately.
– Nick Cardoso
Nov 9 at 9:25
1
@NickCardoso Regarding your question, hope that the down-voter will also provide a reason, as you did in my case. Just up-voted because I found your question very helpful and hope you'll find an answer soon.
– Alex Mamo
Nov 9 at 9:48
|
show 1 more comment
up vote
4
down vote
accepted
up vote
4
down vote
accepted
When you are listening for changes in Cloud Firestore for realtime changes, using Firestore Query's addSnapshotListener() method, it:
Starts listening to this query.
Which basically means that first time you attach the listener, you get all documents that correspond to that particular query. Furthermore, everytime a property within a document changes, you are notified according to that change. Obviously, this is happening only if the listener remains active and is not removed.
Unfortunately, Firestore listeners don't work that way, so you cannot skip that "case ADDED". What you can do instead, is to add add under each user object a Date
property (this is how you can add it) and query your database on client, according to this new property, for all documents that have changed since a previous time.
According to Nick Cardoso's comment, for future visitors that might ask why this behaviour happens, is because the reason he mentioned in his comment. I also recommend see Doug Stevenson's answer from this post, for a better understanding.
When you are listening for changes in Cloud Firestore for realtime changes, using Firestore Query's addSnapshotListener() method, it:
Starts listening to this query.
Which basically means that first time you attach the listener, you get all documents that correspond to that particular query. Furthermore, everytime a property within a document changes, you are notified according to that change. Obviously, this is happening only if the listener remains active and is not removed.
Unfortunately, Firestore listeners don't work that way, so you cannot skip that "case ADDED". What you can do instead, is to add add under each user object a Date
property (this is how you can add it) and query your database on client, according to this new property, for all documents that have changed since a previous time.
According to Nick Cardoso's comment, for future visitors that might ask why this behaviour happens, is because the reason he mentioned in his comment. I also recommend see Doug Stevenson's answer from this post, for a better understanding.
edited Nov 9 at 9:46
answered Nov 5 at 14:29
Alex Mamo
37.9k62557
37.9k62557
Thank for the answer, I try your solution.
– Sky Tracker
Nov 5 at 17:49
Ok, keep me posted.
– Alex Mamo
Nov 5 at 18:04
Hi Sky! Have you tried my solution above, does it work?
– Alex Mamo
Nov 6 at 7:44
This answer is incomplete as it misses a big point (the date solves the issue, but doesn't explain why the behaviour happens). The snapshot provides data from the local cache as well as mutations from the remote. So if you only wan't changes (implying this is a repeated query) it's not fetching (and charging for) everything again. It's getting just the mutations as expected, you just have to handle it appropriately.
– Nick Cardoso
Nov 9 at 9:25
1
@NickCardoso Regarding your question, hope that the down-voter will also provide a reason, as you did in my case. Just up-voted because I found your question very helpful and hope you'll find an answer soon.
– Alex Mamo
Nov 9 at 9:48
|
show 1 more comment
Thank for the answer, I try your solution.
– Sky Tracker
Nov 5 at 17:49
Ok, keep me posted.
– Alex Mamo
Nov 5 at 18:04
Hi Sky! Have you tried my solution above, does it work?
– Alex Mamo
Nov 6 at 7:44
This answer is incomplete as it misses a big point (the date solves the issue, but doesn't explain why the behaviour happens). The snapshot provides data from the local cache as well as mutations from the remote. So if you only wan't changes (implying this is a repeated query) it's not fetching (and charging for) everything again. It's getting just the mutations as expected, you just have to handle it appropriately.
– Nick Cardoso
Nov 9 at 9:25
1
@NickCardoso Regarding your question, hope that the down-voter will also provide a reason, as you did in my case. Just up-voted because I found your question very helpful and hope you'll find an answer soon.
– Alex Mamo
Nov 9 at 9:48
Thank for the answer, I try your solution.
– Sky Tracker
Nov 5 at 17:49
Thank for the answer, I try your solution.
– Sky Tracker
Nov 5 at 17:49
Ok, keep me posted.
– Alex Mamo
Nov 5 at 18:04
Ok, keep me posted.
– Alex Mamo
Nov 5 at 18:04
Hi Sky! Have you tried my solution above, does it work?
– Alex Mamo
Nov 6 at 7:44
Hi Sky! Have you tried my solution above, does it work?
– Alex Mamo
Nov 6 at 7:44
This answer is incomplete as it misses a big point (the date solves the issue, but doesn't explain why the behaviour happens). The snapshot provides data from the local cache as well as mutations from the remote. So if you only wan't changes (implying this is a repeated query) it's not fetching (and charging for) everything again. It's getting just the mutations as expected, you just have to handle it appropriately.
– Nick Cardoso
Nov 9 at 9:25
This answer is incomplete as it misses a big point (the date solves the issue, but doesn't explain why the behaviour happens). The snapshot provides data from the local cache as well as mutations from the remote. So if you only wan't changes (implying this is a repeated query) it's not fetching (and charging for) everything again. It's getting just the mutations as expected, you just have to handle it appropriately.
– Nick Cardoso
Nov 9 at 9:25
1
1
@NickCardoso Regarding your question, hope that the down-voter will also provide a reason, as you did in my case. Just up-voted because I found your question very helpful and hope you'll find an answer soon.
– Alex Mamo
Nov 9 at 9:48
@NickCardoso Regarding your question, hope that the down-voter will also provide a reason, as you did in my case. Just up-voted because I found your question very helpful and hope you'll find an answer soon.
– Alex Mamo
Nov 9 at 9:48
|
show 1 more comment
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53156109%2fhow-to-skip-initial-data-and-trigger-only-new-updates-in-firestore-firebase%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown