timescale.infoIssue #47 · IDs, time-based indexing, and storage vs. user-interface
- 2020 editor
- issue
With the addition of UUIDs in #46, this brings a few questions when refactoring - - Should Timeline.UI be brought into a separate package / into purescript-timeline? - Why is Timeline.Data concerned with the time-based sorting of events and timespans etc, while Timeline.UI focuses on maintaining integrity? Aren't these roles reversed? - How do ids play into this field? From what I understand, stored data should follow the following philosophy: - Concern yourself only with data integrity - this could include, present state of the user interface - i.e. sorting type, and manual item placement due to drag-and-drop - Indexing can be done elsewhere, only elegant representation of the total set of data should be of concern - Is totally serializable to some format, either binary or text (json), s.t. it will always be isomorphic - Future-proofing versions (see #34) Likewise, the following for user interfaces: - Mandatory indexing should take priority - this technically means, indexing that is always required - for instance, the timeline graph itself requires all items in the graph to be sorted "horizontally" by their time field, so that panning, zooming, etc can be done quickly. - for our intents and purposes, we'll only be "looking" (modifying / viewing) one level of the "elegant" data type at a time - this implies flattening - focus should also be taken on the speed of editing data at one of these levels. - stored as a mutable set of Signals, and mutated with Queue semantics For both: - there should be a clear isomorphism between the two structures - modification to the UI structure at one "level" should update an existing stored structure (via existing index) relatively quickly. IDs Therefore, IDs will be treated as the fundamental binding between stored and user-interface representations of this data - modifications, deletions, and insertions will be represented by unique ids. They will constitute the identity, fundamentally, of a piece of data. Whether or not the user interface decides to store "all events" as a Map UUID Event or something, it doesn't matter - the consistency of the data being stored, and likewise being represented to the user, fundamentally relies on a unique ID - why not univesrally unique? *Archived by the Wayback Machine on 15 September 2020; the repository has since been deleted from GitHub.*
Sources
Open Issue #47 · IDs, time-based indexing, and storage vs. user-interface in the timeline