[02:11:15] duesen: addshore: Last I heard, there was rough consensus to phase out ConnectionManager (which was only added for Wikibase, and seems to have been either obsoleted or originated in a misunderstanding). But I now see new methods added to it. https://gerrit.wikimedia.org/r/c/mediawiki/core/+/700069 [02:11:39] I'd prefer not to take on additional methods in wikimedia/rdbms, but I guess we need to resolve this and decide one way or the other. [07:05:27] Krinkle: If it is going from core we will likley just copy it into WIkibase! [07:05:45] And if it is going to be removed from core I guess someone should flag it as deprecated! [10:19:34] Krinkle: I think the critical thing is SessionConsistentConnectionManager. That still seems useful to me. Why do you think it originated from a misunderstanding? [10:19:34] I recall that I originally wanted to build that functionality into LoadBalancer, but after some discussion, that was thought to be a bad idea. So we implemented it as a wrapper. [17:51:19] From what I understand, it redundant with injecting LB (if you need multiple conns) or DB conn ref (if you need only one). I don't see what it adds to copy the same class but proxy two of its methods [17:51:59] We already have too many ways do getConn(), which we're working to reduce [19:21:18] Hi, I am considering adding fields to the Linter table to enable more advanced Special Pages Linter error searching for editors and as I study the implications of doing an ALTER TABLE to the Linter table to add two new fields, the shepherding required by the DBA group and SRE and others appears to be, ah, significant. [19:21:18] I need a DBA friend to discuss this process and maybe rethink how this works and implement the search capability using a new table instead of altering the existing one and doing a data migration. [19:21:18] Please recommend a contact in the DBA group and SRE group that I can chat with about this effort. [19:23:03] How big are the linter tables (row count) on various wikis? [19:24:01] schema changes to lesser used tables like that shouldn't be as scary as a change to MW core's revision, for example :P [19:52:49] Reedy: Hmm, just adding up the various types of errors, some looks like maybe 30 million rows across all categories of lint errors. [19:53:16] Is that on one specific wiki? Or across all wikis? [19:53:23] I could just look myself [19:53:25] * Reedy does [19:54:04] ~22.6M for enwiki [19:54:27] sbailey: Depending on how you look at it... Now would be a really good time for doing this sort of schema change, with a DC switch coming up [19:55:45] fun. dewiki is more like 322K [19:57:46] The process is fairly simple though.. If you make the schema change seperate to the code that depends on it, get the schema change merged, and then create a ticket for the DBAs to action it, for these smaller tables they do get it done fairly quickly [19:59:31] Reedy: So there is a ton of waste in the current schema, where I can dramatically reduce the amount of space the linter table consumes, if I consolidate errors on the same page into two tables but I haven't through through a dramatic change in table schema for the Linter, though I think Subbu would like me to. [19:59:31] My concerns would then be selects with where over joined tables and the performance of that (I think). [20:11:59] Reedy: the schema change I am currently proposing adds two columns to the table, and would need a data migration process to come along after the columns are added to reparse and move selected data from an existing blob to the two fields, so not a huge deal but required (or we could just regenerate all linter data in a day or two long run of all pages against parsoid, but that isn't needed). [20:11:59] Getting the search code to work dual mode should not be too hard, though there are UI issues that maybe harder to dual mode, maybe I can grey out the select box if the new columns are not yet in the lnter table at the time the code runs. [20:11:59] Anyway, any DBA you can recommend I chat with about approach and who might shepherd the alter table for me? [20:12:52] Manuel does most of the schema changes in production [20:17:12] Ok, I will chat with him being very courteous, thanks for all the advice, it is a new world outside of the island of Parsoid :-) [22:49:53] > PHP Warning: mb_strpos(): Offset not contained in string [22:49:55] > /srv/mediawiki/php-1.37.0-wmf.9/extensions/AbuseFilter/includes/Parser/AbuseFilterCachingParser.php:1272 [22:50:11] I don't think that was there before in prod, in case anyone was working on this recently