search

CascadesCarnivoreProject / Carnassial

Carnassial: Simplifying Remote Camera Data
Other
3 stars 0 forks source link

Handle Timelapse Templates that have been modified after an imageDatabase has been created. #42

Closed saulgreenberg closed 8 years ago

saulgreenberg commented 8 years ago

When an image set is read for the first time, the template is stored internally in the .ddb file. When the image set is opened later, the template read in is compared to the one in the .ddb file if they differ materially (e.g., in the number and names of columns) a dialog box is raised informing the user of the incompatibility.

This should be changed, where the user is shown the difference between the two, and asked whether they want their database updated to reflect the changes (e.g., new columns, deleted columns, renamed columns).

The solution will be to construct such a dialog box, and - depending on the user response - use the AddColumn/DeleteColumn/NewColumn methods found in SQLWrapper to alter the .ddb tables accordingly.

twest820 commented 8 years ago

Something also to consider is syncing changes not involving column add/remove/rename. Examples of such include width changes, default value changes, and add/remove/rename of choice values. Mostly these aren't blocking as users can flow .tdb adjustments by applying the editor to the .ddb without need to modify DataTable and MarkersTable schema. But I nearly decided to implement the safer parts of such syncs (width, tooltip, copyable, visible) in ImageDatabase.OnExistingDatabaseOpened() a few days ago.

saulgreenberg commented 8 years ago

Good point. As part of this discussion, its also worth considering the role of a separate template file. That is, there is no reason why a user can't open the .ddb file instead of the template if they want. There are advantages and disadvantages to requiring a separate template that we should go over.

saulgreenberg commented 8 years ago

Actually, this isn't correct. The old Timelapse always uses the information provided in the .tdb file to construct the UI. The only time it uses the one kept in the database is when timelapse sees an issue that is not resolvable and gives the user the option to use the internally stored one. While we can resolve this when we do try to look for inconsistencies and have them corrected in later versions, the change to disallow some options from passing through means that the user can get into a state where some things are just not possible. For example, if the original template had 'Date' visibility set to false when the data db was created, there is no way to later reveal that data field in the UI if, for some reason, the chief biologist or the user wanted that displayed without hacking the database. I only now realize that you changed the way Timelapse works on these fields - it should go back to the old way.

We can discuss this, but I believe it quite important that the main template .tdb file be the master for now, as it can lead to real problems when the biologists need to change UI (vs. database) aspects via the template.

twest820 commented 8 years ago

Doesn't meet the current bar. Can be revisited if needed.