database migration file doesn't take account of new fields and tables
Initial error was the accession_number_hashed - there will be more!
Comments (8)
-
reporter -
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>>
-
reporter @dplatten, apart from a spelling mistake (now corrected),
0002_add_new_tables_fields.py.inactive
appears to work in place of0002_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 runningmigrate remapp
isn't needed. But it doesn't hurt. -
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 myexact
version and the min/max parameters are ignored. Pah. -
reporter Filtering issue is dealt with in issue
#291 -
reporter Added field to StoreSCP model for keep_alive flag, and added it to the migration file. Refs
#292and#290→ <<cset 29a5e214afef>>
-
reporter Removed original upgrade migration file, renamed new one. Refs
#290→ <<cset efec0916b9a3>>
-
reporter - changed status to resolved
Modified the upgrade docs to reflect new migration file name. Fixes
#290→ <<cset d3054b3e30ba>>
- Log in to comment
Attempt to capture all the changed fields to make the migration file for 0.6 to 0.7 upgrade. Refs
#288,#290→ <<cset edef61d4ed2e>>