I already run Mediawiki on ADODB (see bug 9767 over at Bugzilla) and concur with what I see as the intent of the start of this thread. As I began to move from 1.14 to 1.15, I noted a problem with Special:RecentChanges and Special:RecentChangesLinked that are characterized in that message (i.e., queries formed by the union of two or more subqueries). Those compound queries are being put together at the level of the special page, and are constructed from arrays of subqueries. I would much rather see a function added at the Database class level to form compound queries from subqueries, since the alternative is to introduce conditional code at the special page level that is selected on the basis of the SQL syntax of the database engine -- and that approach has been justifiably opposed by Brion and others in the past. I would then override that function in my derived DatabaseADODB class, as I already am doing with several other functions. Further, my current approach to this particular issue produces different results for SQL Server 2000 and SQL Server 2005. For SQL Server 2005, the approach uses CTEs (Common Table Expressions) -- but that approach is not available in SQL Server 2000, so I must resort to either using tables in the tempdb and accumulating results, or simply approximating the MySQL approach -- which is what I actually do. The problem with the UNIONs in SQL Server 2000 is that you can't limit the results of the component queries in addition to the results of the compound query, as you can with CTEs in SQL Server 2005.
On Fri, May 15, 2009 at 7:20 PM, George Herbert george.herbert@gmail.com wrote:
On Fri, May 15, 2009 at 5:01 PM, Thomas Dalton thomas.dalton@gmail.comwrote:
2009/5/15 George Herbert george.herbert@gmail.com:
Domas, I assume you're still on this list - can you give us some
background
why we're not on a closer to current release MySQL within the WMF environments?
Upgrading for the sake of upgrading is always a bad idea. The question should also be "why should we upgrade?" not "why shouldn't we upgrade?".
Eventually, supportability and bugfixes for newer versions surpass those for older versions.
I am not one for making changes just because, but having done long term system architecture and administration in industry, refreshing things every year or two years (be they Solaris, Linux, Oracle, or other tools) is a really good practice.
Among other things, if you wait too long between refreshes, you run the risk that it's too hard to roll the next upgrade, because of lack of experience and preparation with upgrading.
Upgrades should be regular and expected. Frequent is probably a mistake, barring active bugs, but trying to freeze anything in time works poorly over 5 year timespans. You eventually end up with hardware that's obsolete to the point of unreliability, software that's obsolete to the point of unreliability, etc.
-- -george william herbert george.herbert@gmail.com _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l