Wikibase has a set of versatile IdGenerators. We want to extract them into an external library and make them reusable in other extensions.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | • noarave | T214310 Resolve (initial) TechDebt of WikibaseSchema | |||
| Declined | None | T215405 Extract Wikibase IdGenerator(s) into a library and use it in WikibaseSchema |
Code should be taken from Wikibase as WikibaseSchema already has outdated versions of the things.
start security review
This should not / will not need a security review as the code is already deployed in production and has been since 2013 :)
The current state is that IdGenerator things occur in Wikibase, and then also in WikibaseSchema.
The main differences between the 2 are that the WikibaseSchema code allows a table name to be passed in but Wikibase has one hardcoded.
The Wikibase code has the option to use a separate db connection for getting the IDs.
It still make sense for these to just live in a little self contained lib that can be used by both extensions and possibly in other places in the future.
The library would benefit from the Wikimedia\Rdbms already existing as a separate composer library (which looks like it will be done as part of T158929), but we can still make the library before then and just write that this is a library for use with mediawiki?
This then causes other things for us to think about, as we could not declare compatability with the db lib, as it doesn't exist, which could cause future problems, however unlikely as the id generator things don't bind to the db classes in a complex way.
Dependancy:
On the flip side, this isn't currently causing us any problems, so maybe we just don't do it now, keep and eye on it and maybe pick it up once mediawiki is actually split into some more useful libs.
Moving to "Ignored" for now @alaa_wmde, does that column placement sound about right?
Maybe it should be in "Blocked" as it is really blocked on a db lib from core.
yeah we need some column for such cases.
We can call the column Ice Box ? that's a name I'm used to for stuff we wanted to freeze for later for whatever reason.. and then the ones that are to be ignored for real (so not freezing anymore) we would resolve them as invalid eventually (afyer being frozen until next sync meeting?)
So the fact that we are not imminently going to do this is shown by the fact it is not on the campsite board.
Then in terms of the wikidata board, the hold column is essentially this icebox.
Low prio also set to show that we could do this, but it isn't in any way prioritized.
I guess we want to also then keep it on the exploration board, so we dont re add it back and re evaluate? but maybe it being in hold on the wikidata board is enough?