gistfile1.txt

                                Tracks
                                ======

Author: Oliver Charles
Date: 2010-09-23 12:05:39 BST



Table of Contents
=================
1 Problems with track edits 
    1.1 Single user, simple 
        1.1.1 Data 
        1.1.2 Scenario 
        1.1.3 Sequence of operations 
    1.2 Single user, multiple edits 
        1.2.1 Data 
        1.2.2 Scenario 
        1.2.3 Sequence of operations 
    1.3 Ideas for solutions 
        1.3.1 Pre separate tracklists 
        1.3.2 Edits communicate 


1 Problems with track edits 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

There is currently a fairly large problem with the "edit track" edit
type. This edit type edits a track on a tracklist, such as changing
artist credits or duration. However, a tracklist can be shared between
multiple mediums. The majority of the time, when editing a track we
want this to only happen for the medium the track is on (consider this
the "common case").

The simple solution here then is to have the ability to separate
tracklists out between all mediums that use it. A tracklist has a 1:1
correspondence with tracks, such that a track can only belong to a
single tracklist. This means that to duplicate a tracklist, we also
have to duplicate all tracks on this tracklist.

This now introduces the fundamental problem that tracks being edited
may change ID.

Consider the following scenarios:

1.1 Single user, simple 
========================

1.1.1 Data 
-----------

      Releases: R1 and R2
      Mediums: M1 (for R1) and M2 (for R2)
      Tracklists: TL1 (shared on both M1 and M2)
      Tracks: TL1 contains T1 and T2

1.1.2 Scenario 
---------------

      User U1 wishes to edit T1 on M1, but not affect T1 on M2.

1.1.3 Sequence of operations 
-----------------------------

      - Edit E1 is created indicating an edit for <T1, M1, $changes>.
      - E1 is applied (at some point)
        - TL1 is separated, causing the creation of TL2
          - TL2 contains T3 and T4.
          - T3 is a duplicate of T1, with $changes applied
          - T4 is a duplicate of T2
        - M1 is updated to use TL2

1.2 Single user, multiple edits 
================================

1.2.1 Data 
-----------

      As before

1.2.2 Scenario 
---------------

      User U1 wishes to edit T1 and T2 on M1, but not affect M2 at all

1.2.3 Sequence of operations 
-----------------------------

      - Edit E1 is created indicating an edit for <T1, M1, $changes>
      - Edit E2 is created indicating an edit for <T2, M1, $changes>
      - E1 is applied (at some point in time)
        - Same as before
      - E2 is applied
        - At this point in time, E2 *thinks* it needs to edit T2
        - However, E1 already split the tracklists apart, it *really*
          needs to be editing T4.
        - *BOOM*

1.3 Ideas for solutions 
========================

    As mentioned before, the fundamental problem is that the track ID
    may change in the time between an edit being created, and the edit
    being applied.

1.3.1 Pre separate tracklists 
------------------------------

* Separate tracklist edit 
  
  One solution is to have a "separate tracklist" edit which is
  always an auto edit, and just does the duplicating of
  tracklists. Before an "edit track" edits are created, we create
  and apply this edit type.
  
* Separating tracklists always happens on edit insertion 
  
  Basically the same as before, but instead of an edit type, we
  just do this on edit insertion for all track affecting edit
  types. This at least reduces the size of the edit history for
  entities.
  
* Problems with separating tracklists 
  
  It problem won't be possible to them back together, if all the
  edits fail. We would need a edit_tracklist table to link edits
  to tracklist IDs, and check if all edits failed. This seems the
  only safe situation of when can merge tracklists back together
  (because we are confident there have been no changes).
  

1.3.2 Edits communicate 
------------------------

      We implement some sort of case where edits can communicate with
      one another. This would allow the first edit that splits
      tracklists to communicate with other edits, letting it know
      important information, most likely a list of
      < old_track_id, new_track_id > tuples.

      Determining how edits communicate (efficiently selecting the
      list of edits) is difficult though. Again, this would probably
      require either edit_track or edit_tracklist tables to be
      created, possibly both.

      Originally myself and Kuno thought about the idea of having
      edit_groups with metadata, and an easy way to find grouped
      edits, but that doesn't handle the situation of another editor
      making an edit that splits tracklists.