Import/export dance(s) feature

contradb / contra

Find and share contra dances.

http://contradb.com

GNU Affero General Public License v3.0

13 stars 5 forks source link

Import/export dance(s) feature #391

Open djpohly opened 6 years ago

djpohly commented 6 years ago

It would be nice to be able to transfer data easily between installations of ContraDB, whether for testing/development, migration, backups, or offline use - kind of like MediaWiki's Special:Export feature.

Proposed UI:

Subtle "Export Results" link below a page of results that generates and downloads a file in some easily parseable format (JSON, structured text, or such)
Link (maybe in logged-in user's drop-down menu) to special page for importing data which accepts a file upload

Since it's something I'd probably forget myself on the first go, the feature should ensure that users may only export data which they are authorized to view.

Ideas for future extensions of this feature:

Export programs (including programmed dances)
Some form of duplicate detection on the import side
Export only what has changed since a given date/time

Could be tied into #106 given a way to translate between each other's formats (sort of like git-fast-import).

cranhandler commented 6 years ago

We also have this https://github.com/contradb/contra/issues/97

which reaches the 'regular backups' but not 'user backups'.

cranhandler commented 6 years ago

What would be approximately the time commitment of the earliest implementation of this?

[ ] Subtle "Export Results" link below a page of results that generates and downloads a file in some easily parseable format (JSON, structured text, or such)

This per se is something we need to protect users' data integrity, and would be the first step the 'import' portion of this issue, and to https://github.com/contradb/contra/issues/392 which I expect will share parameters.

Creation of the format is likely the tough part, yes? To date we're still not 100% on our implementation of some figures heys, some waveforms, promenade, swingthrough and I would request we not write the parser for those until we are 100%.

dcmorse commented 6 years ago

There are a couple of concepts bouncing around here.

There's import from another format, c.f. #106 Cary Ravitz format.

Then there's moving dances/programs among contradb database replicas, so that users are empowered to take control of their data and public data. Goal: they don't have to trust our backup scheme.

Then there's moving dances/programs among contradb database replicas, when they are running different versions of contradb. This seems in general super-hard, and a lot of work, except in the special case of moving an entire database, in which case you run something along the lines of bundle exec rails db:migrate. (that's to go up in version - to go down in version, I generally haven't been maintaining that path, but it could be done in the future if there was a need).

Am I understanding right?

djpohly commented 6 years ago

I think the libfigure JSON would be the biggest sticking point. Is libfigure versioned and backwards-compatible, or could it be made to be so from a certain point forward?

dcmorse commented 6 years ago

It's not formally versioned, but there is code in the migrations that moves from lower versions to higher versions that works and is smoke tested. Sometimes moving from lower versions to higher versions requires humans go fill things out, like when waves puffed out to being programatically encoded. Code to go from higher to lower versions is not written, but it could be if there were a good reason to do so.

I've written an importer and an exporter from libfigure format to another predecessor format (also designed by me), and I learned some lessons from that. Chief among them: Don't spend a month writing a solid importer/exporter if you only have 30 dances to translate. :)