daniel added a comment.
In https://phabricator.wikimedia.org/T107595#2235621, @brion wrote: > Thoughts: > > would RevisionContentLookup need both title and revision id in the same lookup, or should we rely on database integrity for ids, and have a separate lookup method as a shortcut for 'latest revision of page with this page id or title'? Still undecided. In theory, the revision ID is enough, at least with our database scheme. But for a different implementation, knowing the title may be useful, and having to look it up again would be annoying. > Slot name uniqueness/registration? Are we good enough with ad-hoc names? Hopefully extensions won't conflict, etc. we pret much have tons of cases where conflicts are possible though so this doesn't really increase our conflict surface. I agree: something to keep in mind, but not worse than content model ids or namespaces. > On the updater interfaces I'm not sure we need an explicit begin, versus implicitly beginning in the constructor (RAII)... Or are nested transactions still not safe to rely on? Hmmmm Nested transactions are not safe to rely on. As far as I can tell, we really only use transactions for batching. There are no ACID guarantees. I would not want a constructor to start any kind of process. Beginning the update may grab locks, so it should be explicit (and possible return a magic scoped variable that rewinds if it goes out of scope before a commit). > Derived and virtual slots still make me go "hmmm" as well though I can see some benefits. Need to think more as we flesh stuff out, get some good usage examples. The main benefit is: give extension a place to put their stuff, so they don't come up with 20 solutions, all a bit different and crazy. Provide a standard mechanism for storing derived content along with a page revision. And if we do that, allowing virtual slots is dictated by the caller not wanting to know whether a slot is virtual or not. > I'll think about the xml dump format (do we have any notes on that I missed?) but it should be straightforward to add new elements alongside <text> to store the non-primary slots. Slight confusion here: "primary" to me means "user generated, not derived". Maybe I should start saying "original". So yea, we want to put other original content into additional <text> tags. But those text tags will not only have to have a slot name, we also need to record the length, hash, content model and serialization format for each <text> blob. Do we want to put them into attributes, or change the structure around some more? > What to do with derived and virtual slots on dump? I would tend to not include them I guess. Indeed, yes. The purpose of the dumps is to back up, import and export the content that users generated. And if we want derived content in the dumps afterall, it's easy enough to add that. Some more questions: - do we need "slot handlers", or can all handling be done based on the content model? - do we need some kind of configurable orchestrator for combining the view, edit interface, diffs, etc of the available slots? Would that be configured per namespace? TASK DETAIL https://phabricator.wikimedia.org/T107595 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: RobLa-WMF, Yurik, ArielGlenn, APerson, TomT0m, Krenair, intracer, Tgr, Tobi_WMDE_SW, Addshore, Lydia_Pintscher, cscott, PleaseStand, awight, Ricordisamoa, GWicke, MarkTraceur, waldyrious, Legoktm, Aklapper, Jdforrester-WMF, Ltrlg, brion, Spage, MZMcBride, daniel, D3r1ck01, Izno, Wikidata-bugs, aude, jayvdb, fbstj, Mbch331, Jay8g, bd808 _______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
