--- Comment #6 from Nathan Larson <> ---
Yeah, if there weren't a particular use case I had in mind, I would totally
say, Leave it as is for now. There are a few different options for Inclupedia,
that I can think of. (1) discard the enwiki rev_ids of imported revisions. (2)
keep those rev_ids in the mirrorbot table, in case they're needed later. (3) do
what I'm doing now, which is import them with the enwiki rev_ids, and use
higher rev_ids for Inclupedia-only revisions. (4) add a few fields to the
revision table, or add new tables, similar to what you see at

Option 3 seemed the simplest, especially since options 1 and 2 would still have
required another field to be added indicating that the revisions were imported
(it's pertinent information when people are browsing through). If I go with
option 3, then an auto-increment starting point has to be selected, e.g. 3
billion. It might take decades, but there will eventually be a collision. These
are wikis whose life spans are projected to be possibly decades or centuries
for all we know. For peace of mind, I'd prefer to not set up the equivalent of
a Y2K issue.

The next decision is, (a) change the schema for everyone, or (b) change it for
just Inclupedia. I don't really mind changing it just for Inclupedia. Part of
the point of filing the bug was to figure out which direction people wanted to
go in. We can WONTFIX and then I'll just add SQL files to MirrorTools for the
necessary changes. This is especially true in light of the fact that intval's
behavior can be changed by going to a 64-bit system.

Since I was going to make a schema change anyway, I figured I'd ask, Hey, want
to just change it in the core?

You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
Wikibugs-l mailing list

Reply via email to