26
[4]: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/586448
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wik
h or
without error code changes), and for a few the error metadata may be
changing (e.g. "botMax" changes to "highmax" for limit-type warnings in
non-back-compat error formats).
This change will most likely go out to Wikimedia wikis with 1.35.0-wmf.19.
See https://www.medi
- "foobar", formerly interpreted as "0".
Most clients should already be using correct formats, unless they are
taking direct user input without validation.
This change will most likely go out to Wikimedia wikis with 1.35.0-wmf.19.
See https://www.mediawiki.org/wiki/
nd
list=allusers fully in line with that already used for meta=userinfo and
'blocked' errors from various actions.
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
mediawik
tps://phabricator.wikimedia.org/P8990
[3]: AbuseFilter: https://phabricator.wikimedia.org/P8989
[4]: SpamBlacklist: https://phabricator.wikimedia.org/P8991
[5]: ConfirmEdit: https://phabricator.wikimedia.org/P9076
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
_
e advantage of
the index on (log_namespace, log_title, log_timestamp). If possible you
might also change it to "order by log_title, log_timestamp" to make it even
faster, although I suspect that won't fit with whatever you're trying to do.
What was the original query before yo
tps://tools.ietf.org/html/rfc7231#section-3.1.1.5
[2]: As seen for example at https://www.mediawiki.org/w/api.php.
[3]: See https://phabricator.wikimedia.org/T176370 for progress on the
migration.
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
> (
-> select
-> (@row_number_2:=@row_number_2 + 1) as rownumber,
-> ipb_address
-> from ipblocks
-> where ipb_by_actor = 1789 -- HujiBot
-> order by ipb_range_start
-> ) as lead
-> on lead.rownumber = ipb.rownumber + 1;
[..
cks" view could use a where clause specific to the
> ipblocks entity table like "WHERE exists( select 1 from ipblocks where
> ipb_reason_id = comment_id and ipb_deleted = 0)" and exclude the tests
> for other entities (image, filearchive, revision, etc).
>
See also https
org/T25227>
[3]: https://phabricator.wikimedia.org/T25227#4902709
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/m
more information on the deployment process.
Note that accesses to the actor table may be slow, as are accesses to the
comment table. Improving that situation is being tracked at
https://phabricator.wikimedia.org/T215445.
--
Brad Jorsch (Ano
"[61e9f71eedbe401f17d41dd2] Exception caught: Testing",
"data": {
"errorclass": "InvalidArgumentException"
}
}
],
"trace": "InvalidArgumentException at ...&quo
AM Brad Jorsch (Anomie)
wrote:
> As you may have been aware, we've been working on changing how MediaWiki
> stores comments: instead of having them as fields in each revision
> (rev_comment), log entry (log_comment), and so on, we're storing the text
> in a central "comm
[1]: https://phabricator.wikimedia.org/T198214
[2]: https://phabricator.wikimedia.org/tag/parsoid-php/
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.o
On Mon, Sep 17, 2018 at 11:07 AM, Brad Jorsch (Anomie) <
bjor...@wikimedia.org> wrote:
> We've been writing to the new fields and tables since the end of February
> 2018, and have back-populated them for old revisions, log entries, and so
> on.
>
Correction, the back-popul
ields makes
use of the CommentStore class that was introduced in MediaWiki 1.30.
You can watch https://phabricator.wikimedia.org/T166733 (and any subtasks)
for more information on the deployment process.
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
__
h as the rvdifftotext parameter to action=query&prop=revisions,
will not be updated for MCR. Code using these parameters should be updated
to use action=compare instead.
[1]: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/448160
[2]: e.g. https://en.wikipedia.beta.wmflabs.org/w/api.php?modul
lient is checking for specific missing parameter error codes, it
may need to be updated for the changed codes.
[1]: https://phabricator.wikimedia.org/T200155
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce m
iawiki-api-announce is a low-volume announce-only list, while
mediawiki-api is a discussion/help list (like this one) that also gets all
the announcements.
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Wikimedia Cloud Ser
ly enough
possibility to tell us not to count on it remaining available.
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Wikimedia Cloud Services mailing list
Cloud@lists.wikimedia.org (formerly lab...@lists.wikimedia.org)
htt
k[1] one of our DBAs warned this list that
that ability is not guaranteed or supported, and changing that is indeed a
possibility.
[1]: https://lists.wikimedia.org/pipermail/cloud/2018-January/000169.html
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikim
On Sat, Dec 30, 2017 at 10:55 PM, Huji Lee wrote:
> and log_id > 9406768;
>
As I said earlier, it was bad advice to use log_id rather than
log_timestamp for this query.
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia F
_action.
It looks like logging_userindex is useful for queries that are targeting
indexes user_time, log_user_type_time, log_user_text_type_time, and
log_user_text_time.
Any of the three views should work for the primary key and the type_time
and times indexes.
--
Brad Jorsch (Anomie)
Senior Softw
*" in
"count(*)" does not cause the database to fetch all fields.
If anything, "count(*)" might be ever so slightly faster since it's
literally staying "count the number of rows" rather than "count the number
of rows where the constant 1 is not nul
do the subquery in batches to merge in your client code.
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Wikimedia Cloud Services mailing list
Cloud@lists.wikimedia.org (formerly lab...@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/cloud
bug in PHP (or HHVM, if that's what you're using). You
should file it upstream with details on how exactly to reproduce it.
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Wikimedia Cloud Services mailing list
26 matches
Mail list logo
