[04:02:24] Krinkle: made a few cleanups at https://gerrit.wikimedia.org/r/677417 [04:33:28] landed and rebased https://gerrit.wikimedia.org/r/c/mediawiki/core/+/672514 [04:36:40] and https://gerrit.wikimedia.org/r/c/mediawiki/core/+/673331 [04:47:15] and https://gerrit.wikimedia.org/r/c/mediawiki/core/+/643385 [04:47:16] :) [05:14:20] Krinkle: I have a bunch of amendments locally [08:23:11] Krinkle: l had to shorten the RL line in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/677417 [14:50:17] genocation: Hi :) [15:09:55] Hello!! :D [18:06:16] Hey performance team. If I was thinking about doing an upsert on actor table, should I be aware of any pitfalls from performance perspective, or is its just fine, or is in a huge no-no and my hands will be chopped off? [18:07:27] Pchelolo: upsert instead of insert seems good to me. we do that a fair bit, slowly increasing use of I think. [18:07:50] we have a spot where we do 'delete, insert, update' instead [18:07:56] theres some inefficienies around multi-row upserts that I think AaronSchulz would like to optimise a bit more, but for single rows I think there aren't any caveats to know about. [18:08:29] cool. I'll explore this idea more then. thank you [18:08:56] for mysql it translates to "INSERT … ON DUPE UPDATE" [18:11:07] yeah, I've read the code and it does exactly what I want. Was just wondering if there's any pitfalls there [18:11:55] assuming good primary keys, not that I know of. otherwise there may be some locking risks there, but I don' know if those would be worse/different than with regular inserts in a longer transaction. [19:45:21] * Krinkle sees patch [19:45:32] Pchelolo: aha, I was wondering where, I didnt find it in actor store. [19:45:35] it's user::newSystemUser [19:45:40] the gift that keeps on giving [19:45:52] maybe we should treat system users more like namespaces. [19:46:06] oh I am working on cleaning that all up and gosh it's a fascinating method. [19:46:13] e.g. consider the list of system users immutable, and if someone changes it, run a maintenane script to usurp any users with that name [19:46:32] it'd be more intentional rather than lazy/accidental. [19:46:54] we may also wnat to make them not localisable/configurable which just seems like asking for trouble. [19:47:16] or perhaps even a particilar character or prefix for system users [19:47:23] anyway, "not a priority" [19:48:22] yeah.. there's some very advanced usage of system users in translate extension - they are used there more like 'transient, temporary users' [19:48:31] like WelcomeBot@system or something like that [19:48:38] coudl even use the foreign system for that [19:48:59] since it kind of is a foreign actor [19:49:11] that's a very interesting idea... [19:49:41] foreighn actors don't have a user account though, so we would first need to convert more codebase to UserIdentity [19:50:02] to make it work nicely without User being messy. [19:50:04] we wouldn't have this infinite list of things that go wrong, like password tokens, user rights, bot groups, user pages, user rights, people immitating system users etc. [19:50:17] or losing your account on a random day that someone first runs a script on your wiki [19:50:42] yeah, something to consider :) [19:50:54] this sounds like a very nice idea... I'll look into it more. [19:51:03] the reason I'm thinking this is because I was very surprised that you had to delete or change a row in Actor table [19:51:07] which is very strange indeed [19:51:44] deleting rows in actor is fascinating - that's actually just updating a user_id on an existing actor [19:52:59] anyway, that patch is a very early WIP, I'm gonna iterate on it more. [19:53:27] yeah, but it feels wrong to update an actor tuple. they're meant to be immutable especially the actor/user_id part [19:53:36] the name is kind of a cache of user_name and could change [19:53:49] (if we keep that? I don't remember if we store it there or not for registered usrs) [19:55:58] the actor_name is in actor table for both registered and anon. It's updated when user name changes [19:56:12] ah okay [19:56:24] for registered users the name is in both user and actor tables.. [19:56:32] I guess that's a fair compromise between "update 2 million rows in 5 tables" and "update 1 field in 1 table" [19:56:35] to update it in two tables [19:56:40] and not have a third join to deal with [19:56:51] yeah, I assume that was the motivation