CODEWITHSUNDEEP
androidfirebasefirebase-realtime-database
Voy
Voy

Reputation: 6274

Query.equalTo(value) or Query.startAt(value).endAt(value) causes delay in sync

My queries with .equalTo() return out-of-date data when used with addListenerForSingleValueEvent, while removing .equalTo() causes the listener to return updated data. Any idea why?

.

I'm using the following query to fetch user's posts from Realtime Database with persistance enabled on Android:

mDatabase.child("posts").orderByChild("uid").equalTo(id)

where id is the id of the current user and each post stores its author's id as a field.

When .equalTo(id) is present, the new posts for the particular user are not returned in that query for the first few minutes. Even more, it seems to affect other queries for the same root ("posts") that contain .orderByChild. Eg, following would also fail to recognise the new post:

mDatabase.child("posts").orderByChild("archived")

Once I remove the .equalTo(id) the behaviour goes back to normal. I'm using addListenerForSingleValueEvent. Tried it also withaddValueEventListener which fires two events, one without the new post, one with it. Without .equalTo(id) both single and non-single listeners return the new post in the first callback. Restarting the app doesn't seem to help straight away - the first event stays out-of-date for the next few minutes. The new post is successfully fetched by different queries in other parts of the application (eg mDatabase.child("posts").child(id))

Any idea why .equalTo() causes such behaviour and how to avoid it (other than using non-single listener and ignoring first event)?

Note 1: same thing happens for .startAt(id).endAt(id)

Note 2: other parts of the Realtime Database are functioning normally, device is connected to the internet and new posts are containing the valid uid field matching the current user.

Update 26/10/2016

Calling mDatabase.child("posts").startAt(key).limitToFirst(4) also produces similar behaviour when trying to query a segment of the database (in our case to implement infinite scroll). It seems that explicitly adding .orderByKey() fixes that particular problem: mDatabase.child("posts").orderByKey().startAt(key).limitToFirst(4). Though the issue outlined in the original question remains.

Upvotes: 0

Views: 365

Answers (1)

Andre Romano
Andre Romano

Reputation: 1012

I've ran into the exact same problem as you, and after experimenting with almost everything, I've managed to solve it on my end.

I'm scanning barcodes and fetching foods that have the scanned barcode:

Query query = refFoods.orderByChild("barcode").equalTo(barcode);
query.addListenerForSingleValueEvent(new Value ... })};

On my rules i had

".indexOn": "['barcode']"

and after i changed it and took the "[]" out as in:

".indexOn": "barcode"

it started working delay free, where before it would take something like 5 minutes to udpate.

Upvotes: 1

Related Questions