Wikimedia Bugzilla is closed!

At present, we have several kinds of uniqueness constraints:

1) a property's label must be unique (per language, among properties)

2) an item's combination of label and description must be unique (per language, among items, if a description is given)

3) an item's sitelink must be unique (per target wiki).

Each of these is implemented separately; some are checked on every save, some are checked only on creation and modification of the respective part of the entity. Some checks are expensive or awkward (the label+description uniqueness requires a self-join on a big table with a very complex condition).


Proposed solution:

* We add a "fingerprint" table, with two columns: fp_entity and fp_identity. fp_entity holds the id of the entity that fingerprint belongs to, fp_identity holds the fingerprint (as a string, which may be a hash). There's a composite unique key over both columns, and a separate index on the fb_identity column.

* To check for conflicts, we compute all fingerprints of the candidate, and check if we find any of them in the database. If so, there is a conflict.

* Fingerprints can be computed as sensitive or insensitive as we like (by e.g. converting to lower case or stripping whitespace before hashing)

* as an added bonus, we can look up any entity by a fingerprint (e.g. items by sitelink or properties by label) without touching the terms table.

Example fingerprints for the three use cases mentioned above:

1) property label:  $fp_fingerprint = "label:{$language}:{$hashOfLabel}";

2) item label+description:  $fp_fingerprint = "label+desc:{$language}:{$hashOfLabelAndDescription}";
// Note: if there is no description in that language, no fingerprint is generated for that language

3) item sitelinks:  $fp_fingerprint = "sitelink:{$site}:{$hashOfPageTitle}";