The twitpocalypse strikes!

[GoogleCodeExporter]

What steps will reproduce the problem?

1. Attempting to sync Twitter

What is the expected output? What do you see instead?

"psycopg2.DataError: integer out of range"

What version of the product are you using? On what operating system?

Rev. 90

Please provide any additional information below.

To correct this, I just logged into my database administration tool
(phpPgAdmin) and changed the data type for the twitter_id column in the
twitter_tweet table from "integer" to "bigint".

http://www.twitpocalypse.com/

Original issue reported on code.google.com by brandon....@gmail.com on 29 Jun 2009 at 6:55

[GoogleCodeExporter]

I fixed a similar bug after the Flickrpocalypse a while back:

http://code.google.com/p/django-syncr/issues/detail?id=32

We should be using BigIntegerField to store all IDs.

Original comment by xdiss...@gmail.com on 2 Jul 2009 at 8:55

[GoogleCodeExporter]

Here's a patch against r90.

From within trunk: patch -p0 -i syncr_twitter.diff

Original comment by xdiss...@gmail.com on 2 Jul 2009 at 9:18

Attachments:

• syncr_twitter.diff

[GoogleCodeExporter]

Excellent, thanks!  I wasn't sure what the appropriate Django field was for 
that.  I
appreciate it!

Original comment by brandon....@gmail.com on 2 Jul 2009 at 10:37

[GoogleCodeExporter]

This is a pretty sneaky bug that disappears with some backends - particularly 
SQLite. Definitely look out for this 
if you develop with a different backend than your prod environment. I believe 
both Twitter and Flickr have 
officially recommended using strings to store all IDs anyway, so my revised 
statement is that BigIntegerField is 
*not* the way to go in the long run, but will get you fixed up until a major 
syncr update. Perhaps this is a good 
time to bring up handling schema migrations for field changes in syncr?

Original comment by xdiss...@gmail.com on 3 Jul 2009 at 11:09

[GoogleCodeExporter]

For now I have applied the BigInteger patch to the Twitter models.py. I'm 
willing to switch to strings for IDs, but 
if we start using CharField() we're limited to a max_length. I guess this 
shouldn't be a problem for (potentially) a 
long, long time, so I'm probably wrong to be concerned about it, but for 
someone with a very large database of 
sync'd items it could add a lot of disk space, no?

Original comment by jesse.l...@gmail.com on 7 Jul 2009 at 8:53

• Changed state: Accepted

[GoogleCodeExporter]

I have been using the same code from a while back and I still have 
PositiveIntegerField for twitter_id but I dont 
have any problem. And by the way I am using mysql (could that be it)....

Original comment by yash...@gmail.com on 3 Aug 2009 at 5:53

[GoogleCodeExporter]

For what it's worth, I *just* started having this problem today. I'm also using 
MySQL, so yash888 - if you're 
still around, I'd be interested to see if you started seeing this as well.

Changing the twitter_tweet.tweet_id field to BIGINT fixed it for me. I'm 99% 
sure that the problem was 
Twitocalypse II:

http://groups.google.com/group/twitter-development-talk/browse_thread/thread/361
4bb896bf6ad3e

They mention a new max status ID of 4294967296. My most recent tweet was 
incorrectly being recorded as 
that -1. Attempts to save anything higher failed until doing an alter on the 
database.

Original comment by matthewt...@gmail.com on 25 Sep 2009 at 11:33

[GoogleCodeExporter]

Yeah this issue is because of twitter id exceeding  max int. The solution is to 
use BigINT or use CharField for 
twitter id. I personally used CharField....

Original comment by yash...@gmail.com on 29 Oct 2009 at 9:55

[GoogleCodeExporter]

Issue 72 has been merged into this issue.

Original comment by yash...@gmail.com on 29 Oct 2009 at 10:07