Open Bug 1428513 Opened 2 years ago
URL column in the history table should have a unique constraint
It'll be nice if our storage layer enforced more of the domain-specific constraints. In case of history (a flat set of URLs), the constraints are straightforward. There isn't a good reason to have two history records with different guids, and the same URL. That is indicative of a problem either in the browser itself, or in the synchronization layer (see Bug 1428496 for an example). In case of desktop sync, the "problem" of uploading duplicate history records might be more of a "condition" - see https://bugzilla.mozilla.org/show_bug.cgi?id=1428496#c1. We already have an index on URL, so we wouldn't be incurring a large cost here here. Migration will need to consider how to "smush" duplicates together, if this "smushing" should be propagated to other clients in presence of Sync (via tombstones) or kept local, and how to deal with sets of visit records. Regarding propagation via Sync, it might be reasonable to keep this smushing local. This means two things: 1) we won't have to own purging of records across the sync ecosystem, and 2) history tables will diverge across clients (even further than they have diverged by now). Both of these points have a set of various implications, so think them through. We'd also need to either preemptively fix any possible sources of duplication (such as fixing Bug 1428496), or chart a path to deal with a fallout - that is, fail gracefully and predictably when it happens. But realistically we'll have to do all of the above for this work to actually land. This work is a potential can of worms. The pay-off is a stricter, less error-prone data layer, fixing any and all data duplication bugs, trimming user profiles a little bit, etc.
You need to log in before you can comment on or make changes to this bug.