Hi,
That query of 'ors=sad=all' looks a little goofy, I would suggest
'q=sad+OR+all' if you're looking for both. I just tried a few
different things and it seems like this is an issue with combining
max_id and since_id. The max_id parameter was added to make sure the
page parameter works correctly. I've oddly never tested using it to
circumvent the pagination limit. I'll take a look at it but please
open a Google Code issue (http://code.google.com/p/twitter-api/issues/entry
) so I don't forget.
A quick aside about the pagination limit: It's not there to make
it hard on people or somehow hide our data, it's there to make
searches faster. When you go back in time we have to read data from
disk and replace recent data in memory with that older data. The
pagination limit is there to prevent too much of our memory space
being taken up by old data that a very small percentage of requests
need.
Thanks;
— Matt
On Mar 11, 2009, at 09:11 AM, Ronnie wrote:
Hey Matt,
Nish is right, I don't see a warning message that the max_id that
max_id is adjusted unless since_id is not specified
Here's a sample json request:
http://search.twitter.com/search.json?ors=sad=all&rpp=100&since_id=1309564503&max_id=1311104069&page=1
The id of the first result is higher than the requested max_id but
there was no warning message
Thanks,
Ronnie
On Mar 11, 8:57 am, nish <[email protected]> wrote:
HI,
I am facing the same problem as Ronin. The output does not contain
any warning message. Just that the max_id passed in is ignored and a
new max_id much higher than the one passed in is assigned.
Thanks,
Nish.
PS: If since_id is not specified, then I do see a warning message
that it was adjusted, but thats a different case.
On Mar 11, 7:48 am, Matt Sanford <[email protected]> wrote:
Hi Ronnie,
Did the output contain any sort of warning message? When the
max_id is too old we have to adjust it and the output will contain a
warning saying as much.
Thanks;
— Matt Sanford
On Mar 11, 2009, at 02:34 AM, ronin wrote:
Hi Doug,
I tried the approach that Karthik mentioned but it didn't quite
work.
So after the first 15 pages worth of tweets were retrieved, I set
the
max_id to the id of the last tweet and page =1
For example,
id of last tweet = 1000
max_id = 1000
page = 1
then the next query (for the next 15 pages)http://search...?
max_id=1000&since_id=100&page=1...
The results returned basically ignored the max_id and the ids
were all
greater than the stipulated 1000.
Any idea why the max_id was ignored ? Is there a way to retrieve
tweets beyond 15 pages?
Thanks for the help in advance,
Ronnie
On Mar 10, 4:45 pm, Doug Williams <[email protected]> wrote:
Nish,
The way I read your question, it sounds like you are trying to use
the
max_id parameter incorrectly. max_id allows you to specify the
maximum
status id to return. It is the way to limit the results to
statuses
before a
given status id. It is complementary to the since_id parameter,
capping the
results of a query at the top of the result list where since_id
closes the
bottom.
Doug Williams
Twitter API Supporthttp://twitter.com/dougw
On Tue, Mar 10, 2009 at 7:20 PM, nish <[email protected]>
wrote:
Hi,
Were you able to get more than 1500 tweets using the max_id
method?
I somehow cannot get it. I am using the search JSON API and
whenever
I set the max_id looks like the server resets it to something
else.
Thanks.
On Feb 24, 11:59 am, Karthik <[email protected]> wrote:
Please confirm, if the following is allowed?
1. Set rpp=100 and retrieve 15 pages search results by
incrementing
the param 'page'
2. Get the id of the last status on page 15 and set that as the
max_id
for the next query
3. If we have more results, go to step 1
On Mar 11, 8:57 am, nish <[email protected]> wrote:
HI,
I am facing the same problem as Ronin. The output does not contain
any warning message. Just that the max_id passed in is ignored and a
new max_id much higher than the one passed in is assigned.
Thanks,
Nish.
PS: If since_id is not specified, then I do see a warning message
that it was adjusted, but thats a different case.
On Mar 11, 7:48 am, Matt Sanford <[email protected]> wrote:
Hi Ronnie,
Did the output contain any sort of warning message? When the
max_id is too old we have to adjust it and the output will contain a
warning saying as much.
Thanks;
— Matt Sanford
On Mar 11, 2009, at 02:34 AM, ronin wrote:
Hi Doug,
I tried the approach that Karthik mentioned but it didn't quite
work.
So after the first 15 pages worth of tweets were retrieved, I set
the
max_id to the id of the last tweet and page =1
For example,
id of last tweet = 1000
max_id = 1000
page = 1
then the next query (for the next 15 pages)http://search...?
max_id=1000&since_id=100&page=1...
The results returned basically ignored the max_id and the ids
were all
greater than the stipulated 1000.
Any idea why the max_id was ignored ? Is there a way to retrieve
tweets beyond 15 pages?
Thanks for the help in advance,
Ronnie
On Mar 10, 4:45 pm, Doug Williams <[email protected]> wrote:
Nish,
The way I read your question, it sounds like you are trying to use
the
max_id parameter incorrectly. max_id allows you to specify the
maximum
status id to return. It is the way to limit the results to
statuses
before a
given status id. It is complementary to the since_id parameter,
capping the
results of a query at the top of the result list where since_id
closes the
bottom.
Doug Williams
Twitter API Supporthttp://twitter.com/dougw
On Tue, Mar 10, 2009 at 7:20 PM, nish <[email protected]>
wrote:
Hi,
Were you able to get more than 1500 tweets using the max_id
method?
I somehow cannot get it. I am using the search JSON API and
whenever
I set the max_id looks like the server resets it to something
else.
Thanks.
On Feb 24, 11:59 am, Karthik <[email protected]> wrote:
Please confirm, if the following is allowed?
1. Set rpp=100 and retrieve 15 pages search results by
incrementing
the param 'page'
2. Get the id of the last status on page 15 and set that as the
max_id
for the next query
3. If we have more results, go to step 1
