Now, there are various ways to model redirects. I have
tried a few:
1) 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
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
2) 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.
3) 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.
4) 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,
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.
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.