User talk:Leucosticte/Inclumedia2

Primary key limits
Inclupedia will import revisions from Wikipedia, but also have its own revisions. These will all be stored together in the revision table, whose primary key is rev_id. rev_id is an unsigned int, which means that it will max out at about 4.2 billion revisions. Currently, it's at 600 million. I have two options:
 * 1) Change it to an unsigned bigint, and start Inclupedia revision auto-incrementing at 1 quadrillion. That way, it will be centuries before there is a collision between Inclupedia revisions and imported Wikipedia revisions. The main problem is that I'd have to change not only the primary key but every field that stores those keys. E.g. the value of is also stored in, , etc. so those would all have to be changed to unsigned bigint as well.
 * 2) Keep it as an unsigned int, and start Inclupedia revision auto-incrementing at 3 billion. Eventually, there will be a horrific collision when Wikipedia reaches its 3 billionth revision sometime in the mid-21st century. It will be even worse than dealing with a Y2K problem because there will be no possible solution that doesn't have severe drawbacks that cripple functionality. Users and developers will curse my name.

Let the record show that I, Nathan Larson, chief software architect for Inclupedia, on 4 February 2014, after considering these possible consequences, decided, "Option #2 requires less work right now, so I guess I'll go with that one." Leucosticte (talk) 16:23, 4 February 2014 (UTC)
 * Later, the solution will be that when we go to bigint, we'll change all the numbers to a quadrillion higher, and anything that tries to get a diff like, e.g., https://en.wikipedia.org/w/index.php?title=9223372036854775807&diff=577460345&oldid=575620595, there'll be a workaround that will check to see if those revisions are existent for that page, and if not it'll look to the number that's a trillion or quadrillion higher. It shouldn't be a big deal. Leucosticte (talk) 11:54, 6 February 2014 (UTC)