If I recall correctly, I had to spend a good deal of time convincing you that since page moves don't affect `recentchanges`, and thus you can't use "rc_namespace =X AND rc_title = Y" in the WHERE clause (just rc_timestamp), without the code failing to find matches that it should. So you probably could lose the patronizing attitude ;)
But yes, the timestamp index use a good practice measure, but it also wasn't fragile and cryptic. Adding dummy rows defies the name/definition of the table, and it thus becomes harder for other devs to figure out (especially if dummy rows are not mentioned in the help/MW.org stuff, which I suspect they wont be). It's annoying as hell to have to review patches/fix bugs/add features to cryptic code. I remember getting hung up on tail() in checkuser just to add search method to it.
I am always trying to write my code cleaner, and I already use more comments. Readability is important, and I'm sure Brion can attest to that.
Domas Mituzas wrote:
Hi!
Aside from the "bogus entries" and "looks fragile" bits?
Bogus entry? What about broken links? Are they bogus entries? "Looks fragile"? Of course, having query recaching scripts, that quite often get killed, is not fragile at all. And everyone knows that we don't have any fragile features, site_stats is the most trusted and stable counter in the world. :)
I don't like it either.
Well, no wonder. You're after elegant solutions and procedures: "The schema change requirement was noted and made quite clear. If it wasn't taken live before the software was updated, it's no fault of the development team. " As you remember, that schema change was not needed at all, and one- line change fixed the performance completely. It wasn't elegant (dedicated indexing, tables, columns, etc - wow, how nice), but it was practical.
And I appreciate practical solutions, cause we have a site to run.
Cheers,
Domas Mituzas -- http://dammit.lt/ -- [[user:midom]]
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l