* All callers are calling it this way and it breaks
hhvm when declared statically and called dynamically.
Change-Id: I894e615fd828615384aa8457a16a759c8aa416ef
And added/removed spaces around some other tokens,
like +, -, *, /, <, >, =, !
Fixed windows newline style
Change-Id: I0b9c8c408f3f6bfc0d685a074d7ec468fb848fc8
ERROR: Closing brace must be on a line by itself
Squiz.WhiteSpace.ScopeClosingBrace.ContentBefore
- For non-empty scopes it means the closing brace must be on a separate
line. This is already the case in most classes in some cases the "lazy
closing" is still used.
array(
'x' ); // Moved } to next line
function () { return 'x'; } // Moved } to next line
case 1:
stuff; break; // Moved break to next line
- For empty function it serves as a visual distinction between there not
being a scope block / function body and there being an empty function
body.
function foo(); // No body
function foo() {} // Empty body - violation
function bar() { // Empty body corrected
}
Change-Id: I0310ec379c6d41cc7d483671994d027a49f32164
Doxygen expects parameter types to come before the
parameter name in @param tags. Used a quick regex
to switch everything around where possible. This
only fixes cases where a primitve variable (or a
primitive followed by other types) is the variable
type. Other cases will need to be fixed manually.
Change-Id: Ic59fd20856eb0489d70f3469a56ebce0efb3db13
Added/removed spaces around logical/arithmetic operator
Reduced multiple empty lines to one empty line
Removed wrong tabs before comments at end of line
Removed too many spaces in assigments
Change-Id: I2bba4e72f9b5f88c53324d7b70e6042f1aad8f6b
* In newer versions of PG, a "hex" escaping format is used, which
totally breaks things like SqlBagOStuff since the pg_unescape_bytea
function still works the old way (it does not use a DB handle).
Setting the format to the old way via SET fixes this.
Change-Id: I9f5a64922acd2d954880790f42ba4efafaed314e
Created new method for creating the group by/having and order by sql,
this avoids code duplication in each database with a overridden
makeSelectOptions.
This fix the group by/having/order by for DB2/MSSQL to support array
conditions. Fixed the having for Postgres for array conditions.
Change-Id: I0fbcb3e8e68d995d93be0bf3d0a347788a39194a
For PostgreSQL only:
SavepointPostgres tries to rollback already committed/rolled
back transactions, so after it got committed, don't try
to rollback it again in SavepointPostgres::__destroy.
This happens only when trying to INSERT IGNORE something
without having a transaction open first (e.g. during
unit testing).
Thanks to: OverlordQ <overlordq@gmail.com>
Change-Id: I40ff757a7e2c6ff21f73e1ecd35754e1981f1941
Added configuration options ($wgDBssl, $wgDBcompress) and related
connection flags (DBO_SSL, DBO_COMPRESS) to allow SSL/TLS and
compression on database connections. The flags are only observed if
the functionality is supported for that type of database (e.g.,
SQLite will ignore both flags as neither are supported).
Currently, only MySQL and PgSQL have support for at least one of
these flags in their PHP extensions. MySQL supports both flags and
PgSQL supports the SSL flag only.
Change-Id: I7b4d3ba82ccab0eed4a19e3b4e7bc0b4eb881262
Signed-off-by: Tyler Anthony Romeo <tylerromeo@gmail.com>
* Removed unused and obsolete set() and safeQuery() functions.
* Removed unused deprecated constructor functions.
* Removed unused limitResultForUpdate() cruft function.
* Removed unused standardSelectDistinct(), it's better to just follow the standard for all queries.
* Removed other cruft functions unused by core/extensions.
* Made some internal functions protected.
Change-Id: I90be88ea740834a417a17d7751f1be7bac4eae4e
Fix handling of $insertOptions in
DatabasePostgres::insertSelect
Looks like this change:
https://gerrit.wikimedia.org/r/#/c/3962/
(or 646a9490f7)
mishandled badly INSERT IGNORE (instead of
silently broken support for it it introduced
PHP error).
Looks like we have no unit test to cover
the use of Database::insertSelect in the code.
Change-Id: I4f7d8c9bd9e413d8ffa23c1d0c0628a25c28d45c
* SqlBagOStuff should not turn off automatic transaction
control just like that. Keep previous
connection for PostgreSQL and SQLite
* 94633ff448 introduced
rollback on error to restore sanity
for the connection. Don't do this
if you are in the middle of INSERT IGNORE
and we have a savepoint open.
Making sure query syntax errors don't
get silenced by our "wonderful" implementation
of INSERT IGNORE is bug 35572.
Change-Id: I841b03895e1189c47307fefb1516c4c7c4102e25
PostgresUpdater fails on PostgreSQL 8.3.14:
> Changing 'image.img_metadata' default value
> A database query syntax error has occurred.
> The last attempted database query was:
> "ALTER TABLE image ALTER img_metadata SET DEFAULT '\x'::bytea"
> from within function "".
> Database returned error "22P02: ERROR: invalid input syntax for type
> bytea"
Patchset 2:
> Database returned error "42883: ERROR: function
> generate_subscripts(int2vector, integer) does not exist
> LINE 7: (SELECT generate_subscripts(isub.indkey, 1) AS g
> ^
> HINT: No function matches the given name and argument types. You
> might need to add explicit type casts.
> "
Change-Id: I6e1811ded0eedad9c0eb0df715698c45aaf8e3f0
Changeset 1 of https://gerrit.wikimedia.org/r/#change,3365:
763b57f9f2af131a2d8e65f520a23c00109be0e1
got mis-merged in changeset 2:
f752cf8042
And introduced into master wth
0a792a1dcb
Also, marking all new functions as @since 1.19
since we want to have them there later.
Patchset 2: whitespace fixes
Patchset 3: Fix <?php
Patchset 4: rebase to current master
Change-Id: Ic7d940dfec8890de20197128505962375fac4f06
Bug 35572 - Blocks appear to succeed even if query fails due to wrong DB
structure
When emulating INSERT IGNORE ignore only SQL Error Code 23505
- unique key violation
http://www.postgresql.org/docs/9.1/interactive/errcodes-appendix.html
All other error codes (missing column, syntex error, whatever)
should unconditionally abort the transaction and show internal
error to the user.
Patchset 2: Fixed whitespace.
Patchset 3: More whitespace. And ()'s.
Patchset 4: Yet more whitespace.
Patchset 5: rebase & fix conflict in release-notes
Change-Id: Ic32bff9fff46bce124273156d224fa01b8adc008
* PostgresField now reports column default value
* DatabasePostgres::indexAttributes reports index
details
* Perform schema update in one transaction
With this change we can sucessfully update
MediaWiki 1.7.3 schema to trunk^Wmaster
Patch set 2: Rebased against master. PLEASE check carefully
to make sure I got those conflicted files right.
Conflicts:
includes/db/DatabasePostgres.php
includes/installer/PostgresUpdater.php
Change-Id: Iebb6855e8f6f44470bbb1dc5ab9ac1abb513adfe
Upgrade to 1.19 on Postgres fails due to incomplete query when trying to
defer foreign key for externallinks
* FieldInfo::conname() should return NULL not "" when constraint
is not present
* Re-create missing constraint on schema update
Change-Id: I7ca351e07d228afdf4a5c3bef365f42a27c9ac45
Follow-up to r15791.
You can lie to me, but not to your installer.
Make DatabasePostgres::tableExists to check for real table names, not
faked ones.
DatabasePostgres is currently lying to the rest of the MediaWiki that
"mwuser" table is actually called "user" and that "pagecontents" is
called "text". While MediaWiki does not care, the installer (and updater
do).
This allows us to overcome first hurdle in getting MediaWiki 1.7.3 to
update to trunk on PostgreSQL and uncover further bugs.
For this commit to actually do something, we rename those tables when
upgrading to match what we have in maintenance/postgres/tables.sql
And by the way, tell installer not to check for "user" table, since most
PostgreSQL users will have "mwuser" instead. Picking "archive" instead.
Patchset2: wrapped commit message at 72 chars
Change-Id: Ic874e92bb1adda3430d3292423d4f3617c25456c
You can lie to me, but not to your installer.
Make DatabasePostgres::tableExists to check
for real table names, not faked ones.
DatabasePostgres is currently lying to the rest
of the MediaWiki that "mwuser" table is actually
called "user" and that "pagecontents" is called
"text". While MediaWiki does not care, the
installer (and updater do).
This allows us to overcome first hurdle
in getting MediaWiki 1.7.3 to update to trunk
on PostgreSQL and uncover further bugs.
For this commit to actually do something,
we rename those tables when upgrading to match
what we have in maintenance/postgres/tables.sql
And by the way, tell installer not to check
for "user" table, since most PostgreSQL users
will have "mwuser" instead. Picking "archive"
instead.
[exec] PHP Fatal error: Call to a member function getCoreSchema() on a non-object in /var/lib/jenkins/jobs/MediaWiki-postgres-phpunit/workspace/mw-core/includes/db/DatabasePostgres.php on line 216
* Introduce $wgDebugDBTransactions facility to help
figure out what's going on with transactions.
Currently PostgreSQL only.
PostgresTransactionState can be easily be made more general
to trace all sorts of state machinery.
* Improve r113408: we don't need to full reconnect on error,
rollback is enough.
Rolling back breaks search_path, as PostgreSQL
can manage sessions settings under transaction therefore
we need to improve schema sniffing introduced in r82674
* Introduce few schema handling functions. This could
probably be generalized for other databases like DB2 and Oracle.
* Fix bug 15816 - Add a switch for SETting the search_path
We try to avoid touching search_path at all unless
really necessary. Even in this case we append MediaWiki
core schema to the front of the list.
* No longer add $wgDBmwschema to PostgreSQL role search_path
in the installer. This is no longer necessary as
setting schema on connect should ReallyWorkNow(tm).
* Get rid as much as possible of $wgDBmwschema and
bring us one step closer to fix bug 16794 (wgSharedDB
support).
All references to core MediaWiki schema in PostgreSQL
specific code should now use Database::getCoreSchema()
unless we know what we are doing.
Followup-To: r113408 r82674
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
