After a query error, PostgreSQL transaction is aborted
until it's terminated or the query is closed.
All further queries result in:
ERROR: current transaction is aborted, commands ignored
until end of transaction block
Those subsequent errors are ignored by double fault handling in
DatabaseBase::reportQueryError but they cause all localization
of error messages to fail (unable to issue queries to message
tables) and errors lke
This resulted in a broken MediaWiki screen with
<databaseerror>
<dberrortext>
instead of localized error message.
We need to fully reset database connection because after
pg_connection_reset() various session parameters need to
be set again (like "search_path"), otherwise tables will not be
found.
ERROR: relation "msg_resource" does not exist
ERROR: relation "l10n_cache" does not exist
* Add @since, fix indentation.
* Change default from 'all' to 'mw' as it's the most used (so default fetchLanguageNames() is equivalent to default getLanguageNames()).
* Add the include parameter also to fetchLanguageName() as it's needed in Parser: interlanguage links should only take into account mediawiki names. (Doesn't make a difference with how the functions are now, but could have been later.)
* Made upload() explicitly check $status->successCount rather than isOk() as FileRepo::publish() gives fatal statuses where it used to only give warnings. This way, failed uploads still displace the current image DB row to oldimage rather than do nothing and have the same image row point to a new file (which can cause mismatched metadata).
* Disabled exception about invalid oi_archive_name. This makes things more broken in that when people get this an error on upload (which happens when the FS has no current file but the DB does), the new file is added as the current version in the FS but the DB is unchanged. Thus, the metadata can be mismatched.
Also adding a documentation comment in ResourceLoaderModule to clarify that it is the subclass's responsibility to make sure message blob timestamps are taken into account
* Remove default id/name attributes
* Remove now redundant tests introduced in r110274
* Add tests to make sure label has no 'for' attribute when label isn't null but name/id are unset
* Update tests to not include id="" and name="" when calling with no arguments
* Updating calls to add name/id if needed, and while at it remove useless 'null' params
* Context:
-- Introduced in r109990, r111376, r111315
-- No callers exist that assume these defaults. Forcing an ID that should be unique is annoying and redundant. The name used in the query when submitting a form should be mentioned in the same file where it is used from the submission, never assume what name="" is from unrelated code
-- Same for ID, this is often used in CSS or JavaScript, shouldn't be assumed. (It should be simple to but two simple namespace selectors on a page without getting DOM conflicts)
The user table is not dumped by that tool. The warning notice makes it clear
and will avoid someone having some trouble recovering his precious private
data.
* Right now it's causing testswarm clients to have to this test 3 times, and if until bug 34820 is fixed there is no point in clogging up testswarm with it, making all IE columns uselessly red and making it harder to detect an actual regression
I am reverting, for now, two recent additions made to the table sorting:
- r111884 fractions
- r111829 IP addresses
Both need to be polished a bit more before landing in trunk. Please reapply
in a branch then once reviewed we can merge it in trunk, that will avoid
us a lot of "spam".
