scholarslab/Neatline — Issue #48: Design and implement new data schema across the plugin suite
Author: davidmcclure
Created: 2011-11-14 13:40:11+00:00
State: open

Currently, NL data gets saved like this:

* At the start, the code check to see if there is an extant DC field that _makes sense_ in the context of the NL exhibit.
* If so, that data gets defaulted into the item edit form.
* If the user saves the form with that data, NL creates an association record that ties the extant element text in question to the exhibit id.
* If the use changes the default values, NL detects the change, creates a _new_ element text on the item for that DC field, and then creates the association.
* Because of the multi-part structure of the time data (start date, start time, end date, end time), the associations table for the time data is separate, although it still write all new data as stacked DC Date elements on the item record.

In order to move the data stores off of the DC records, we need to create a series of Neatline-specific tables across the plugins to house the data. We need to nail down the specific structure of this. There are various difficulties and conceptual kinks - for example, does it make sense to store vector data on the Maps plugin, even though, taken individually, the maps plugin never has anything to do with feature data (only features and NL proper do).