[search+api] since_id in Twitter-compatible API doesn't work when using q="#..."
[search+api] since_id in Twitter-compatible API doesn't work when using q="#..."
| Issue ID: | 1987 |
| Issue Category: | bug |
| Component: | search |
| Priority: | normal |
| Status: | fixed |
| Assigned: | brion |
| Version: | 0.8 |
| Milestone: | 0.9 |
| Keywords: | json, search, Twitter-Compatible |
Using the Twitter compatible JSON API (this was not tested with the ATOM one, so i do not know about that one here) there's a problem when using "since_id" and "q=#..." - since_id is simply ignored!
How to reproduce (i will use "#kde" as an example, as that's what i've been working on here):
1) make a query for #kde and save the latest id
2) wget -O - -o /dev/null 'http://identi.ca/api/search.json?since_id=$LATESTID&q=%23kde'
result: the query will return dents with ids below since_id too - the result actually looks exactly like the one issued before!
Doing the very same thing at Twitter works as expected.
Updates
#1
Twitter-compat API... sounds like this belongs on poor Zach's plate. :)
Looks like using extra fields like since_id into the search query hasn't been implemented yet; this might need to wait on some extensions to the search backends to support it properly.
#2
I just found out that this is not limited to tags but also other queries.
Thing is that it's documented (see http://status.net/wiki/Twitter-compatible_API ) and claims to behave just as the original API.
Is there anything one can help here with?
#3
I'm taking this bug onto my stack of search issues since it needs backend support.
#4
Actually I think this'll be easier -- since the notice search returns results in reverse chron order, we can just stop when we reach the cutoff. Heh.
#5
[master ca55d6c] Ticket #1987: support since_id on API notice search methods.
max_id still needs additional work; splitting it out to http://status.net/open-source/issues/2901
You can also subscribe to the
RSS feed for updates to this issue.