Erik Moeller wrote:
Gregory Maxwell:
For every wikidata table there are actually two tables in the database, a item table and a revision table. In item, the key will be constrained to be unique and non-null, in the revision table it will be just non-null. Generally just follow mediawiki for the fields, but rather than text have your data fields.
The scenario of having a basically flat table that is versioned is a simple one. It gets tricky when you have 20 tables which are in complex relations with each other, and you want to revert or view a particular revision. Note that even our current MediaWiki is broken in this respect
- when you view an old version of a page, you see it with the latest
versions of the templates it uses, which can lead to very funny results.
This is mentioned on [[m:Article validation possible problems]] - you can't really rate a particular version going back too far sensibly as it'll show the current version of any templates.
One solution is to have bringing up an old rev attempt to bring up whatever version of each of the templates was current at the time it was saved. This is more work, but old revs are viewed a *lot* less than current versions.
Variation: if a stable link is given in a news story or popular blog or whatever it'd be eminently cacheable. Are old revs cached the way the current version is?
A more elaborate variation on the idea is to save each rev with a list of which versions of the included templates it uses.
(Yeah, I know, go write the code ;-)
The problem with relations of that complexity is that, if you don't want to balloon your tables, (I think) you need a lot of revision pointers between them. I'm going to try to model this with a simpler example. If you want to model something, feel free to help - it is sometimes good if multiple heads work on the same problem and come up with different solutions.
Would the second idea above be useful to this end as well?
- d.