Page MenuHomePhabricator

Create a file containing the core types to upload to wiki
Closed, ResolvedPublic

Description

(Kinda optional, can be bumped to a later phase)

Create a file and provide some documentation on how to use it to upload the core bootstrap files to the wiki. These include, for the beginning Z1/ZObject, Z2/Persistent Object, String, Reference, and List.

By the end of the phase these are joined by Type and Key.

Event Timeline

DVrandecic triaged this task as Medium priority.Aug 13 2020, 1:14 AM
DVrandecic updated the task description. (Show Details)

In my opinion what should be done is a "shadow Object", hardcoded in software like pages in MediaWiki namespace page. They may be edited but their definition (not including labels) can not be edited. Only diff is stored, and the object may be extended in the future.

Yes, that's a great suggestion, and would replace both T260314 and this task.

So when this is being implemented, consider doing the "Shadow Object" alternative, that would work too, and either has the same result.

Thanks @Bugreporter !

DVrandecic lowered the priority of this task from Medium to Low.Aug 27 2020, 9:24 PM
DVrandecic moved this task from Phase β to Phase γ on the Abstract Wikipedia team board.
DVrandecic raised the priority of this task from Low to High.
DVrandecic moved this task from Phase γ to Phase β on the Abstract Wikipedia team board.

Here's a first draft.

https://www.mediawiki.org/wiki/Extension:WikiLambda/Core_objects

It includes Z1, Z2, Z3, Z4, Z6, Z9, Z10, Z11, and Z12.

Errors:

  • It has a dangling references to Z30, which should become the function to do the "standard validation", we don't have that yet (and the ZID can obviously change still)
  • The type of Z4K3 is currently set as Z1, should really be Z8/Function, but that's not created here yet.

(In fact I tried to create Z8, but it completely killed my test system. I will probably file a follow-up task for that)

I was thinking about this - if we want a single file, why not make it a ZObject itself, i.e. a JSON formatted list (Z10) of these Persistent ZObjects? It will need some sort of script like the main MediaWiki maintenance/importTextFiles.php to run I assume...

Why are all the id values (Z2K1) equal to 'Z0' in this file?

I was thinking about this - if we want a single file, why not make it a ZObject itself, i.e. a JSON formatted list (Z10) of these Persistent ZObjects? It will need some sort of script like the main MediaWiki maintenance/importTextFiles.php to run I assume...

In my opinion We don't need to actually import them. The method in MediaWiki namespace page should be used: if an builtin ZObject is absent, it will be read from a static file. In addition, as only part (i.e. label of Object and label of their parameters) can be changed, we only store that part in the database. When requesting a ZObject, the data in database will be combined with data in static file.

Why are all the id values (Z2K1) equal to 'Z0' in this file?

We chose to not risk split-brain issues with the title of the object stored in both MW's metadata and also inside the object in the Z2K1 key, so we splice in the value in [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/WikiLambda/+/refs/heads/master/includes/ZObjectContentHandler.php#59 | ZObjectContentHandler::getExternalRepresentation() ]] instead.

We chose to not risk split-brain issues with the title of the object stored in both MW's metadata and also inside the object in the Z2K1 key, so we splice in the value ...

But that value is kind of critical as an identifier within and between ZObjects - the prefix for related keys for types at least, and of course the value of any references. It means they don't make sense without the MW metadata.

Thinking a bit further ahead, if we were to set up a generic import process for a list of persistent ZObjects, should they preserve the ids (and keys) used within those ZObjects? In general that would probably be impossible due to collisions (id's already taken in the Mediawiki instance). So the alternative is to translate those ids (and any related keys) to a new set. Maybe it would be better if the imported set used a different prefix ("Y" instead of "Z"?) to avoid confusion? Anyway, that's probably not an issue really any time soon.

True. I was wondering if it makes sense for these files to use the Z0. I understand how they make sense for creation later, but for this upload?

I will make variants for any of the possibilities - one content per ZObject, and one with Z0 and one with the ZIDs. So we can use whatever is needed then.

So, now each of the files is available in XML and individually, and with Z0s and as ZIDs. Once we decide which way is easiest, we will remove the others.

Regarding comment T260315#6441028 by Bugreporter, yes, that's a great idea. I will add this to T260314.

Make it a format like this:

{
"Z1": { ...},
"Z2": {...},
}

and upload it to gerrit.

What about instead of this being in a single file, having files Z1.json, Z2.json, etc.?

Change 627932 had a related patch set uploaded (by DVrandecic; owner: DVrandecic):
[mediawiki/extensions/WikiLambda@master] Adding the data for the core files.

https://gerrit.wikimedia.org/r/627932

Change 627932 merged by jenkins-bot:
[mediawiki/extensions/WikiLambda@master] Provide initial bootstrapping ZObjects on installation

https://gerrit.wikimedia.org/r/627932