database migration file doesn't take account of new fields and tables

Issue #290 resolved
Ed McDonagh created an issue

Initial error was the accession_number_hashed - there will be more!

Comments (8)

  1. Ed McDonagh reporter

    Added @dplatten's populate_study_workload_chart_time and populate_unique_equipment_names functions to the automatically generated migration from a 0.6 database to a 0.7 database. Ignored PostgreSQL median for now. Refs #288, #290

    → <<cset ddfeab318c5c>>

  2. Ed McDonagh reporter

    @dplatten, apart from a spelling mistake (now corrected),0002_add_new_tables_fields.py.inactive appears to work in place of 0002_upgraded_openrem_add_median_function_and_populate_display_name_table.py.inactive.

    I have used it to upgrade a 0.6 SQLite database populated with a handful of studies, and it seemed ok.

    I haven't put the PostgreSQL median function back in yet.

    I think with the new migration file, the final python manage.py makemigrations remapp between renaming the migration file and running migrate remapp isn't needed. But it doesn't hurt.

  3. Ed McDonagh reporter

    Tested this on a copy of my production postgres database @dplatten, with the postgres thing stuck back in as an if statement at the end (see 7399102), and it seems to work.

    However, when I filter at acquisition level for particular DLP ranges, it doesn't work! Arrrggghhh! The acquisition name gets transferred, but it is the usual icontains, not my exact version and the min/max parameters are ignored. Pah.

  4. Log in to comment