Hi,
Now, there are various ways to model redirects. I have tried a few:
- first I tried implementing redirects as a "mode" any Entity may have. The
advantage is that redirects can seamlessly occur anywhere "real" entities can occur, e.g. in dumps, diffs, undo operations, etc. However, many operations that are defined on "real" entities are not defined on redirects (e.g. "set label", etc), so we would end up with a lot if "if redirect, do this, else, do that" checks all over the code base.
I agree that this would bring lots of disadvantages to the current code base.
- second I tried implementing redirects as a "mode" any EntityContent may have,
following the idea that redirects are really a MediaWiki concept, and should be implemented outside the Wikibase data model. This still requires a lot of "if redirect, do this, else, do that" checks, but only in places dealing with EntityContent, not all places dealing with Entities.
In my opinion this would work better and I prefer it to #1. However, I guess the data won't be available in dumps etc.
- third I tried using a separate entity type for representing redirects: a
RedirectContent points to an EntityContent, there is no "mode", no need for extra checks, no chance for confusion. However, we break a few basic assumptions, most importantly the assumption that all pages in an entity namespace contain an EntityContent of the respective type.
Agreed this isn't the best idea.
None of these solutions seem satisfactory for the indicated reasons, and also some additional consideration explained below.
- This lead me to come fully cycle and consider another option: make redirects
a special *type* of Entity, besides Item and Property. This would again allow straight forward diffs (and thus undo-operations) between the redirected and the previous, un-redirected version of a page; Also, it would not compromise code that operates on Item on Property objects. But since there are still many operations defined for Entity that make no sense for redirects, we would need to insert another class into the hierarchy (let's call it LabeledEntity) which would be a base class for Item and Property, but not for Redirect.
This would require quite a bit of refactoring, and would introduce redirects as a "first order citizen" into the Wikibase data model.
Yes, this would require a bit lot of refactoring but it seems quite reasonable. I don't know if we should change the whole DataModel for this feature, but perhaps there is no solution that works better than this. The only one I can see is #2 but it has also some disadvantages.
Which of the four options do you prefer? Or can you think of another, better, option?
Below are some more points to consider when deciding on a design:
In a addition to the OO design questions outlined above, one important question is how to handle redirects in the wb_entity_per_page table; that table contains a 1:1 mapping of entity_id <-> page_id. It is used, among other things, for listing all entities and for checking whether an entity exists. HOw should redirects be represented in that table? They could be:
a) omitted (making it hard to list redirects), b) or use the redirect's page ID (maintaining the 1:1 nature, but pointing to a page that actually does not contain an entity), c) or use the target entities page ID (breaking the 1:1 nature of the table, but associating the ID with the accurate place).
For b) and c), a new column would be needed to mark redirects as such.
I would prefer b) as it does not break the idea of the table and makes also more sense if we consider handling redirects as entities.
This are my first impressions of entity redirects. I prefer the options 2 and 4 but don't have a strong opinion. Maybe I will also think of another option later.
Best regards, Bene*