-
Notifications
You must be signed in to change notification settings - Fork 156
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
before
and after
in the API skips over objects with identical createdTime
#2304
Comments
Won't work if there are three bets A@1s, B@1s, C@1s and you've already got A and B; that solution would return A and C. |
Ah lol you're right - I guess you just need f64 timestamps eh |
yeahh lol we really should do a real pagination method. for most APIs we can now, since we use supabase. the current behavior with I think this would be a pretty good task for an open source contribution ;) |
You can do something like: SELECT *
FROM bets
WHERE
(
createdTime = beforeId.createdTime
AND id < beforeId.id
) OR (
createdTime < beforeId.createdTime
)
ORDER BY
createdTime DESC,
id DESC basically using the tuple (createdTime, id). With Postgres directly I think you could actually go even simpler: SELECT *
FROM bets
WHERE
(createdTime, id) < (beforeId.createdTime, beforeId.id)
ORDER BY
createdTime DESC,
id DESC though that’s not supported via the public Supabase API. |
Howdy!
I found a bug where using
before
orafter
in the API url will miss objects. I'll paste in the urls that I used for easy reproducibility, I've just been poking around with my browser. I haven't tested on all endpoints, but just going by the docs, I'd guess that this affects anyGET
that returns a sequence ordered by created time, soGET /v0/markets
,GET /v0/users/
,GET /v0/groups
, andGET /v0/managrams
. Here's an example w/ theGET /v0/bets
endpoint:As of the time of creating this issue, the 0th bet is
C4nKqKXEnPwR6ORnALsa
with creation time1702224677794
. The next bet is1fmJ0FRUEsUc40eYvwMo
with creation time1702152570207
. However, it turns out that the next 8 bets also have the same creation time of1702152570207
.So, if you ask all bets before the 0th, you get bet id 1fmJ0FRUEsUc40eYvwMo as expected:
But, if you ask for all bets after
1fmJ0FRUEsUc40eYvwMo
, it skips the next 8 bets, and the first bet you get isIrAVl6uo04tkBax71DUy
, creation time1702152557761
.I guess that the endpoints are implemented as something like
SELECT * FROM BETS WHERE createdTime < beforeId.createdTime
(excuse my pseudo sql), which will skip over bets wherecreatedTime == beforeId.createdTime
. And, if you doSELECT * FROM BETS WHERE createdTime <= beforeId.createdTime
, that will also includebefore
which would be annoying for the API user.Two solutions that I can think of:
createdTime
to af64
- ie down to the millisecond. It probably would work, but it would be a breaking change and doesn't get to the core of the issue (but it would be easy!)SELECT * FROM BETS WHERE createdTime <= beforeId.createdTime && id != beforeId.id
Also, I wouldn't mind just doing this if someone can point me where to look and what solution you prefer!
Cheers, and Merry Christmas!
The text was updated successfully, but these errors were encountered: