Uploaded image for project: 'MusicBrainz Server'
  1. MusicBrainz Server
  2. MBS-4510

Replicating (perhaps optionally) all tables may be valuable

XMLWordPrintable

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Normal Normal
    • None
    • None
    • None

      At the moment, there is only a subset of our tables that are replicated; some notable non-replicated tables include the edit table and most of the CAA-related tables.

      Though these tables were excluded for various reasons, the situation is the same: when a given otherwise-replicated server wants to keep these tables up-to-date, it's an onerous and non-automatic process (importing a new data dump is the usual way to go). The primary (perhaps only) disadvantage developer-wise of replicating currently-unreplicated tables is that schema changes are more onerous on replicated tables. For clients, the primary (perhaps only) disadvantage is that AFAIK there's no way to selectively replicate only some tables.

      One side-effect of our current situation is that, since we additionally lack a WS for retrieving editing histories, the only way to programmatically extract editing history for a given entity is to scrape the HTML (for up-to-date results) or use a potentially out-of-date (and very large) data dump.

      So: what thoughts do people have on making all tables replicated? Do we need to create a selective-replication mechanism for this to be acceptable? Are there considerations I've neglected to mention?

            Unassigned Unassigned
            ianmcorvidae Ian McEwen
            Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:

                Version Package