Skip to content

Putting all migration data into the database #14

Open
@stuartpb

Description

@stuartpb

This is the logical predecessor of #12 and #13 that doesn't appear to have been given its own issue yet.

Right now, dreamcopter incorporates three pieces when managing a DingRoll migration:

  • the ZIP export from Slack
  • the PouchDB database of original and changed messages
  • the YAML definition of the migration plan

#12 talks about putting the last one into the database; what's really needed, going forward, is pre-emptively putting all the messages from the ZIP export into the PouchDB, when it's imported, instead of only doing it when each individual day is saved, which is what happens right now, and is a weird mess.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions