Skip to content

Latest commit

 

History

History
220 lines (108 loc) · 5.09 KB

MIGRATION_0.10.x_to_0.11.x.rst

File metadata and controls

220 lines (108 loc) · 5.09 KB
Raw

MIGRATIONS from 0.10.x to 0.11.x :

Nota : in the SQL queries below, I use CURRENT_TIMESTAMP because of Postgresql. Adapt it to your own RDBMS.

Django Trigger Happy tables :

To migrate enter,

python manage.py  migrate

if the migration complains that you've already created the table django_th_rss then check the follow :

select * from django_migrations ;

to find

11 | django_th | 0001_initial | 2015-06-10 10:00:00.977958+02

if you dont have it then do :

insert into django_migrations (app,name,applied) values('django_th','0001_initial',CURRENT_TIMESTAMP);

then replay

python manage.py migrate

Django Trigger Happy Module tables :

Evernote :

if the migration complains that you've already created the table django_th_evernote then check it by :

select * from django_migrations ;

check that you dont have those record in the django_migrations table

select * from django_migrations ;

13 | th_evernote       | 0001_initial        | 2015-06-10 10:00:00.977958+02

if its not the case, then add the following by hand like that :

insert into django_migrations (app,name,applied) values('th_evernote','0001_initial',CURRENT_TIMESTAMP);

Holidays :

if the migration complains that you've already created the table django_th_holidays then check it by :

select * from django_migrations ;

check that you dont have those record in the django_migrations table

select * from django_migrations ;

13 | th_holidays       | 0001_initial        | 2015-06-10 10:00:00.977958+02

if its not the case, then add the following by hand like that :

insert into django_migrations (app,name,applied) values('th_holidays','0001_initial',CURRENT_TIMESTAMP);

Pocket :

if the migration complains that you've already created the table django_th_pocket then check it by :

select * from django_migrations ;

check that you dont have those record in the django_migrations table

select * from django_migrations ;

13 | th_pocket       | 0001_initial        | 2015-06-10 10:00:00.977958+02

if its not the case, then add the following by hand like that :

insert into django_migrations (app,name,applied) values('th_pocket','0001_initial',CURRENT_TIMESTAMP);

Readability :

if the migration complains that you've already created the table django_th_readability then check it by :

select * from django_migrations ;

check that you dont have those record in the django_migrations table

select * from django_migrations ;

13 | th_readability  | 0001_initial        | 2015-06-10 10:00:00.977958+02

if its not the case, then add the following by hand like that :

insert into django_migrations (app,name,applied) values('th_readability','0001_initial',CURRENT_TIMESTAMP);

Twitter :

if the migration complains that you've already created the table django_th_twitter then check it by :

select * from django_migrations ;

check that you dont have those record in the django_migrations table

select * from django_migrations ;

13 | th_twitter     | 0001_initial        | 2015-06-10 10:00:00.977958+02

if its not the case, then add the following by hand like that :

insert into django_migrations (app,name,applied) values('th_twitter','0001_initial',CURRENT_TIMESTAMP);
insert into django_migrations (app,name,applied) values('th_twitter','0002_int_to_bigint',CURRENT_TIMESTAMP);

before adding by hand the line below, check that the table django_th_twitter contains the column max_id and since_id as bigint and not just int

if that columns are not bigint add just this

insert into django_migrations (app,name,applied) values('th_twitter','0001_initial',CURRENT_TIMESTAMP);

otherwise add this too

insert into django_migrations (app,name,applied) values('th_twitter','0002_int_to_bigint',CURRENT_TIMESTAMP);

Table to drop :

with the last

python manage.py migrate

you will meet this message :

Running migrations:
  No migrations to apply.
  Your models have changes that are not yet reflected in a migration, and so won't be applied.
  Run 'manage.py makemigrations' to make new migrations, and then re-run 'manage.py migrate' to apply them.
The following content types are stale and need to be deleted:

    django_th | userprofile

answer yes as this one is not used at all

then play again

python manage.py migrate

thus the migration will skip that steps and will continue smoothly