Downgrade and Upgrade Django migration

[HEMENDRA SINGH HADA]

I have a django based application. In this we are providing backup and restore facility for user. DB which we are using is sqlite. So please suggest me how to migrate database accordingly - both downgrade and upgrade for sqlite. 

[Andréas Kühne]

Hi,

I don't really understand your requirements here. If you take a backup you will get the database exactly how the database is now. If you have made any changes to the database layout, you would be able to run migrations again to upgrade the database to the latest again. For this you can use the standard migrations in Django. 

The database stores the level of migrations the database has been migrated to - so you can reload a backup at any stage.

Regards,

Andréas

2018-08-04 16:23 GMT+02:00 HEMENDRA SINGH HADA <hada.he...@gmail.com>:

I have a django based application. In this we are providing backup and restore facility for user. DB which we are using is sqlite. So please suggest me how to migrate database accordingly - both downgrade and upgrade for sqlite. 

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/c103056c-a8e5-410d-adb3-b0d9bc5d1ac5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[HEMENDRA SINGH HADA]

Sorry for making requirement complex. My requirement is like I have released first version of my app. After that we have change some table attribute and also added some new tables in my app DB(sqlite). In this sitution  I need both side compatibility(Downgrade and upgrade) for my application.

On Sat, Aug 4, 2018 at 8:59 PM Andréas Kühne <andrea...@hypercode.se> wrote:

Hi,

I don't really understand your requirements here. If you take a backup you will get the database exactly how the database is now. If you have made any changes to the database layout, you would be able to run migrations again to upgrade the database to the latest again. For this you can use the standard migrations in Django. 

The database stores the level of migrations the database has been migrated to - so you can reload a backup at any stage.

Regards,

Andréas

2018-08-04 16:23 GMT+02:00 HEMENDRA SINGH HADA <hada.he...@gmail.com>:

I have a django based application. In this we are providing backup and restore facility for user. DB which we are using is sqlite. So please suggest me how to migrate database accordingly - both downgrade and upgrade for sqlite. 

--
You received this message because you are subscribed to the Google Groups "Django users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.

To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/c103056c-a8e5-410d-adb3-b0d9bc5d1ac5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.

To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAK4qSCcPJ15gtsDmptp5vv4j4%3D_Q7CLDJq1Z5S5eUv1pqLrcow%40mail.gmail.com.

[Andréas Kühne]

Hi again,

I really don't understand why you need to downgrade anything? If you are running your app with an old version of the code that isn't migrated - just work on that code (you have the code tagged and stored in a git repository I hope?). When you are working on an older codebase - you will need to just create a database that corresponds to your code (by migrating to that version from an empty database). 

Upgrading the database would be done via the standard migrations.

I don't know how to revert migrations though - I do think it's possible....

Med vänliga hälsningar,

Andréas

2018-08-04 17:49 GMT+02:00 HEMENDRA SINGH HADA <hada.he...@gmail.com>:

Sorry for making requirement complex. My requirement is like I have released first version of my app. After that we have change some table attribute and also added some new tables in my app DB(sqlite). In this sitution  I need both side compatibility(Downgrade and upgrade) for my application.

On Sat, Aug 4, 2018 at 8:59 PM Andréas Kühne <andrea...@hypercode.se> wrote:

Hi,

I don't really understand your requirements here. If you take a backup you will get the database exactly how the database is now. If you have made any changes to the database layout, you would be able to run migrations again to upgrade the database to the latest again. For this you can use the standard migrations in Django. 

The database stores the level of migrations the database has been migrated to - so you can reload a backup at any stage.

Regards,

Andréas

2018-08-04 16:23 GMT+02:00 HEMENDRA SINGH HADA <hada.he...@gmail.com>:

I have a django based application. In this we are providing backup and restore facility for user. DB which we are using is sqlite. So please suggest me how to migrate database accordingly - both downgrade and upgrade for sqlite. 

--
You received this message because you are subscribed to the Google Groups "Django users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.

To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/c103056c-a8e5-410d-adb3-b0d9bc5d1ac5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.

To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAK4qSCcPJ15gtsDmptp5vv4j4%3D_Q7CLDJq1Z5S5eUv1pqLrcow%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "Django users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.

To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CACgU_Vj7LqC0Q2Gs7DrwY%3D62%3DySmJkiKE4TTGmptP3K1Q%3DOrkQ%40mail.gmail.com.

[Melvyn Sopacua]

On zaterdag 4 augustus 2018 18:03:21 CEST Andréas Kühne wrote:

 

> I don't know how to revert migrations though - I do think it's possible....

 

Yes, easy. Name the app and migration you want to downgrade to:

 

python manage.py yourapp 0002

 

This would unapply 0003_new_model, 0004_change_new_model and so on.

 

If you want to unapply all migrations of a given app, then you use "zero":

 

python manage.py yourapp zero

 

This unapplies 0001, 0002 etc ...

 

This is documented at the "migrate" management command.

 

This only works when your migrations have a "reverse" operation coded, where RunSQL and RunPython is concerned, otherwise the system will not know how to unapply the migration.

 

If you want a system that automatically reverts migrations to a set version number of the entire project, then you'll need to create some custom code and your tools of choice will be:

 

- A RunPython migration in the project app, that keeps track of which migrations belong to which version ... or:

- You squash migrations when cutting a new release and name them consistently using "--squashed-name". For example: coolapp/migrations/0001_v1_0_0.py, hotapp/migrations/0001_v1_0_0.py, coolapp/migrations/0002_v1_0_3.py

 

With either approach it should be possible to write a management command that gathers all the migrations to unapply and get back to a fixed point in time.

 

But what you really have to be aware of, is that it is destructive: if you added fields to a model and that model has new data in that field during the time it was deployed, rolling back the migration will destroy that new data.

 

So while you can go back, you can't easily go forward again and have that data magically reappear.

For that you need for example one of these packages:

https://djangopackages.org/grids/g/versioning/

 

Probably in addition to custom code.

--

Melvyn Sopacua