Location streaming fixes#8351
Conversation
link2xt
force-pushed
the
link2xt/location-streaming-fixes
branch
3 times, most recently
from
28522ff to
b34bc43
Compare
Stored location ID was not actually used and locations_last_sent timestamp was updated with the current time, possibly skipping locations.
link2xt
force-pushed
the
link2xt/location-streaming-fixes
branch
from
b34bc43 to
c85e622
Compare
| let last_sent = alice | ||
| .sql | ||
| .query_row( | ||
| "SELECT locations_last_sent FROM chats WHERE id = ?", |
There was a problem hiding this comment.
I have not found a better way to test this change. The fix avoids missing locations in a corner case of location arriving right after rendering the message and before evaluating now(), but is in fact mostly a refactoring to avoid passing unused location ID around. This is why the test is basically an implementation test.
| AND (timestamp>? OR \ | ||
| timestamp=(SELECT MAX(timestamp) FROM locations WHERE from_id=?)) \ | ||
| AND independent=0 \ | ||
| GROUP BY timestamp \ |
There was a problem hiding this comment.
Not related to this PR, but this takes an arbitrary row if there are rows with the same timestamp, see https://sqlite.org/lang_select.html#generation_of_the_set_of_result_rows:
[...] If the expression is an aggregate expression, it is evaluated across all rows in the group. Otherwise, it is evaluated against a single arbitrarily chosen row from within the group.
I think instead of GROUP BY it should be ORDER BY timestamp, id DESC, then we can skip a row (in Rust) if timestamp is the same as in the previous iteration. Otherwise we can even send different locations in different chats or messages sent in a row to the same chat.
3 participants
Base for #8345
Location streaming fixes split out of the branch.