[twitter-dev] Re: Status IDs are changing on 21st September

2010-08-26 Thread Spode
I must admit, I'm a little confused on some aspects of this.

Will the new IDs continue on from the old IDs sequentally? Or will
they be completely incompatible with the old IDs?

I have a database of several million tweets that JournoTwit users use.
I don't want to have to start differentiating between two ID types and/
or having to completely clear the database out.

What I haven't seen amongst any of this documentation - is an example
of the new status ids in comparison to the old? That would probably
answer a few questions :D And I assume - Direct Messages will be
undergoing the same transformation?

Spode

On Aug 23, 11:45 pm, Matt Harris thematthar...@twitter.com wrote:
 Hey Developers!

 A while ago we let you know about the new Tweet ID generation service
 we developed called Snowflake and published the source code so you
 could get familiar with how it works. Today, we're announcing that at
 10am PDT on Tuesday September 21st, 2010 Snowflake will be in use on
 our production systems and that status IDs will no longer be
 sequential.

 Snowflake still uses 64-bit unsigned integers but instead of being
 sequential they will instead be based on time and composed of: a
 timestamp, a worker number and a sequence number. For the majority of
 you this change will go unnoticed and your applications will continue
 to function without the need for any changes. In addition the API is
 ready for Snowflake and parameters such as max_id and since_id will
 work as expected. Snowflake does mean Tweet IDs will no longer be
 useful for data analysis, and things like counting Tweets by
 subtracting status IDs will not be possible.

 We listened when you told us about sorting Tweets by ID and knew that
 we needed to keep the ID roughly sortable. With Snowflake if two
 Tweets are posted within 1 second of each other they will be within a
 second of each other in the ID space too. This means although Tweets
 will no longer be sorted, they will be k-sorted to approximately 1
 second.

 The key points:
 * Status IDs will be unique
 * Status IDs will continue to increase - Tweets created later in the
 day will have a higher ID that those created in the morning
 * Order will be maintained for Tweets allowing you to sort by Status
 ID. The accuracy of the sort will be to approximately 1 second,
 meaning Tweets created within a second of each other have no order.
 * All existing API methods will continue to work the same as before
 * Previous status IDs will be unchanged
 * There will be a noticeable jump in the numerical value of status IDs
 when we change.

 You can read more about Snowflake on the Twitter Engineering 
 blog:http://bit.ly/announcing-snowflake

 Best

 Matt Harris
 Developer Advocate, Twitterhttp://twitter.com/themattharris

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk?hl=en


[twitter-dev] Overloaded/Rated on Update

2010-04-27 Thread Spode
I've been having a problem I can't get work out.

When sending a status update or direct message - I often get a 0, 502,
503 or 420 response code. Yet the API suggests that status updates
aren't limited.

The annoying thing is that I'm assuming if I get one of those codes
that it was a failure - but in fact, the posts make it through. This
means I report falsely and people will try and post again - often
ended up with double/triple posts.

Any ideas?

Spode


-- 
Subscription settings: 
http://groups.google.com/group/twitter-development-talk/subscribe?hl=en


[twitter-dev] Re: Since_ID and Search Problem

2009-11-12 Thread Spode

This is STILL a problem. I have a possible theory on what is happening
at a server level.

The search phrases I am using are quite specific - i.e, I may well be
the only person in the world searching for that particular string.


First Call - Because it has a since_id, it assumes that it checks
against the server cache ONLY - and doesn't update the search results.

Second Call - Because there is no since_id, it updates the search
results.

Third Call - Once again, with a since_id, it checks against the cache
only - but because of the previous call, now there are tweets there.


I think Twitter is assuming that if there is a since_id, that it
doesn't need to update the original search. The only way around this
problem is to make TWO API calls, or to process the since_id myself.
That's just not acceptable.


[twitter-dev] Re: Since_ID and Search Problem

2009-11-12 Thread Spode

I've created a screen-cam video to illustrate this problem and how
much of a problem it is...

http://www.youtube.com/watch?v=3a-88MSdqes


[twitter-dev] Re: Since_ID and Search Problem

2009-11-12 Thread Spode

The last video I posted was garbled - but I've re-done it.

http://www.youtube.com/watch?v=qedssv3cBCA


[twitter-dev] Since_ID and Search Problem

2009-11-04 Thread Spode

Hi,

I've been noticing some strange behaviour since last night - but
that's not to say it's not been going on longer.

http://search.twitter.com/search.json?q=JournoTwitrpp=100since_id=5402169538

Performing this search turns up 0 results when it should show 4.

http://search.twitter.com/search.json?q=JournoTwitrpp=100since_id=

Run it with no since_id and it works. Then straight away run the
original query...

http://search.twitter.com/search.json?q=JournoTwitrpp=100since_id=5402169538

And you get the expected 4 results.

What's going on?

Spode (journotwit.com)