amadanmath
commented
7 years ago Vice-versa. We might need #37 to deal with potential holes in data created by migrations.
However, migrations are in theory easy, not much to investigate. The real issue is that, unlike a wipe, it takes effort to write a migration, and because we do not retain the evtc files, there might be missing data that can't be filled in by a migration. Thus, a migration might need to invent dummy data, or we need to code defensively and treat any new piece of information as potentially missing.
For a recent example, consider Xera/Deimos success. success is a new field added to Encounter model, so a migration would be necessary to add the new field to the database. But since we don't have the evtc, the choices were to set all existing Xera encounters to successful, or to unsuccessful (neither of which is quite correct), to leave it undecided (and display, say, in grey), or to wipe the DB and start from scratch without worrying about it.
This is why I say that as long as we're not public, wiping is easier, since we don't need to make those decisions (and also spend time coding them). Once the tool goes public, then we'll have to. But it's not hard, code-wise; just takes time, and decision about what to do with the missing data.
merforga
Need to investigate and set in place a process for data base migration to support releases instead of wiping the DB each time. Suspect solution will also support #37 maybe?