This makes it possible to use with counter UPDATE queries.
Also add some extra sanity checks for input types.
Change-Id: Ibc2b7173e28022b5ba7bb04d11c594313a47a101
Add a query builder class which encapsulates the parameters to
IDatabase::select() and related functions.
Override useIndexClause() and ignoreIndexClause() in DatabaseTestHelper
so that index hints can be tested.
Bug: T243051
Change-Id: I58eec4eeb23bd7fb05b8b77d0a748f1026afee52
Previously it would give FROM followed by nothing which is always a
syntax error. Easier to fix it here than to convert empty arrays to
empty strings in SelectQueryBuilder.
Bug: T243051
Change-Id: I95a9b6a34cfb5c1ca4cf243c4226b5ed4f968035
This is useful for grouping related keys on the same servers to reduce
the need for cache server connections and availability. A cache key that
uses "lockTSE" can already involve accessing several keys during the
read/write cache-aside paths:
a) The value key itself
b) The check key (named after the main key, a common pattern)
c) The mutex key (used if the value looks stale)
d) The cool-off key (used if regeneration took a while)
Any problems accessing the first two could cause extra value regenerations.
Problems with the mutex key could lead to stampedes due to threads assuming
another thread was regerating a soon-to-expire value when, in fact, none was.
A similar problem could happen with cool-off keys, with threads assuming
that another saved the newly regenerated value when, in fact, none did.
The use of hash stops puts the tiny related keys on the same server as the
main cache key that they serve. This is only for hash-based routing, and not
route prefix routing (e.g. All*Route still sends the key to multiple child
routes, but the PoolRoute/HashRoute function will hash differently).
The option is not enabled by default yet.
Change-Id: I37e92a88f356ef1e2a2b7728263040e2f6f09a13
PresenceBooleanDef is causing ParamValidator::getValue() to return null,
while historical Action API behavior had returned false instead.
While it generally shouldn't make a difference since PHP considers both
falsey, and good arguments could be made either way, we can restore the
historical behavior easily enough by having normalizeSettings()
default PARAM_DEFAULT to false.
Bug: T244440
Change-Id: Iee1d8e5753407674adc3f7384989841bc9b44c54
ApiStructureTest has a lot of logic for validating Action API settings
arrays during CI. Some of that logic should be part of ParamValidator
instead.
Bug: T242887
Change-Id: I3c3d23e38456de19179ae3e5855397316b6e4c40
Depends-On: I04de72d731b94468d8a12b35df67f359382b3742
Rename PARAM_IGNORE_INVALID_VALUES to PARAM_IGNORE_UNRECOGNIZED_VALUES,
and make it only ignore the "badvalue" errors thrown by EnumDef for
unrecognized values instead of ignoring every kind of error.
This better matches historical Action API behavior.
Change-Id: Ifdb9063c0a2e82c728e98065e2ac950f4a713552
This fixes a few things in ParamValidator's use of messages:
* Values need to be stringified in various places.
* Don't pass the value to paramvalidator-toomanyvalues, to make it match
apierror-toomanyvalues. We weren't using it anyway.
* Rename "paramvalidator-help-multi-sep" to match
"api-help-param-multi-separate".
* Fix attempts to use messages "paramvalidator-param-default" and
"paramvalidator-param-default-empty" that don't exist.
* EnumDef's logic for selecting between enummulti vs enumnotmulti
was backwards.
* Sort enum values in getParamInfo() output.
* Adjust some message texts to match equivalent former Action API
messages.
Change-Id: I1551a59bd110f12e478de7292a00f9a767cd94ca
Iea6d4a1d forgot to convert non-true values in PARAM_DEPRECATED_VALUES
to MessageValue, as was originally intended.
Change-Id: If5907f2072c1efdeb9ee8d1b06eaeacaf95cab17
When the values being validated come from PARAM_DEFAULT, EnumDef
shouldn't warn about them being deprecated.
Making this happen requires a new option passed through from
ParamValidator::getValue() to ::validateValue() to TypeDef::validate().
Change-Id: I8535f8757485748bccb7a756b71ce61fdf28faa1
testIsWriteQuery() never worked. It was using a non-existing provider,
which caused the test to be skipped with a warning. Access to the
protected method under test also needed fixing.
Change-Id: If35789027f2d6c44a7079e68a1c07c86be72d42b
* Deprecate WebRequest::checkUrlExtension() and have it always return
true. This reverts the security fixes made for T30235.
* Remove IEUrlExtension. This is a helper for checkUrlExtension() which
is not used in any extensions.
* Remove CSS sanitization code which is specific to IE6. This reverts
the changes made to fix T57332, and related followups. I confirmed
that the relevant test cases do not result in XSS on IE8.
* Remove related tests.
Bug: T232563
Change-Id: I7318ea4a63210252ebc64968691d4f62d79a63e9
The values of the constants are supposed to match the keys used for the
corresponding special parameters to Message. This one was different.
Note the values of these constants are considered an internal
implementation detail, as is the format of the XML-ish output of
MessageValue::dump(), so we don't have to worry about compatibility
when changing it here.
Change-Id: If5a7279e661df8c13780552d1dee752215e1d497
Also changing its structure to be more readable and more like
https://w.wiki/CXo
My plan is to add more tables to this test.
Bug: T230428
Change-Id: Ia19d5c875cc95238f7fd7cd9adbed1ddb92af078
We're observing WANObjectCacheTest fail sometimes, possibly due to a
1/825 chance of a cache key being counted as "popular" combined with an
mt_srand() call making this more likely. I tweaked the options to
getWithSetCallback() to avoid the affected mt_rand() call altogether.
I also added a lowTTL option to another getWithSetCallback() call,
eliminating a condition with a 3% chance. It didn't appear to matter
which branch the test took, but I'd rather avoid non-deterministic
behaviour.
There are a few remaining coin tosses being logged, but they all occur
with a chance of less than 10^-5.
Bug: T238197
Change-Id: Iadd3dc00d44b8490210fec97fe1f49236326300f
To help isolate the referenced bug, which is a sporadic test failure
in testGetWithSetCallback().
Bug: T238197
Change-Id: If35d60340c804b6bfe1e9ddfcf53c76373c794b1
Quotes started being added to integers in r4984 (August 2004). Before
that, is_numeric() was used to determine whether to add quotes, so
quotes were omitted from numeric strings, which is obviously wrong.
The idea here is to use the type of the variable to hint to the database
as to whether quotes are needed. The results are somewhat inconsistent,
since some callers do not convert numeric strings obtained from user
input to integers. That makes it a more conservative change. Callers can
opt out of unquoted integers by casting them to string.
The reason for doing this is that quoting integers turns out to be not
as harmless as originally assumed. We found a case of it confusing the
MariaDB query planner, causing inappropriate indexes to be used.
I also made addQuotes() consistently return a string, instead of
returning an integer for boolean values. This was already the case for
MySQL, but it seems like a good idea everywhere.
Bug: T238378
Change-Id: I70473280f542ee5ecd79e187f580807410fbd548
If a string starts with "DELIMITER" but the word is *not* followed by
a space, the code will set $this->delimiter to null, possibly resulting
in all kinds of hard to track errors.
Even more problematic: the preg_match was *not* case-insensitive, but the
condition was. Which means that all non-uppercase "delimiter …" would
result in the same error.
I'm not sure if it's worth keeping the additional string comparison for
performance reasons. Probably not. That comparison is slow as well, and
preg_match is surprisingly fast (when the pattern is properly written,
which it is).
Change-Id: I33944b7a2410f77e67ce7450af0359a88d39f1aa
This commit splits changes from Ic14f5debc53e55d6714 to reduce it to
only strictly needed things. It can be merged immediately.
Bug: T192167
Change-Id: I8c541a66ea13421dbe7fa51d197d5455cc4786eb
Trying to get away with returning a single code and parameter-list that
was supposed to represent both human-readable and machine-readable data
was a mistake.
This patch converts it to use DataMessageValue, which represents the two
separately and also provides guidance for supplying translations of all
the error codes.
This also eliminates the "describeSettings()" method that was trying to
serve multiple use cases (in terms of the Action API, action=paraminfo
and action=help). It's replaced by two methods that each serve one of
the use cases. Also some of the functionality was moved out of the
TypeDef base class into ParamValidator, to better match where the
constants themselves live.
Also I wound up creating a NumericDef base class so FloatDef can share
the same range-checking logic that IntegerDef has. I probably should
have done that as a separate patch, but untangling it now would be too
much work.
Bug: T235801
Change-Id: Iea6d4a1d05bb4b92d60415b0f03ff9d3dc99a80b
This will allow us to easily change the deflate library in future.
Rename the PHP class and i18n to just "Deflate".
Bug: T236210
Change-Id: I88dea5e82a7f672e36556c40b151ac00ff3d044e
