Migrations for dropping columns/tables must not have CASCADE keyword

[Marcin Nowak]

Hi.

My question is about these two:

https://github.com/django/django/blob/master/django/db/backends/base/schema.py#L55

https://github.com/django/django/blob/master/django/db/backends/base/schema.py#L64

Both are loose cannons. All dependent objects are silently destroyed during dropping table or column.

Please fix this.

 

Motivation:

I didn't checked what SQL is generated for dropping column.

As a result Django destroyed silently all my views dependent on the column, which was dropped.

The database I'm using is PostgreSQL.

Kind Regards,

Marcin

[Adam Johnson]

Hi Marcin,

I'm sorry to hear that your views got dropped. I hope they were easy to recreate.

I imagine the reason the migrations framework uses CASCADE is because we assume Django manages all your database. I know without CASCADE, PostgreSQL (at least) can also be hard to fight against with permissions, sequence objects, triggers, and other objects that might be related to a table.

I'm not sure how feasible it would be to just remove the keyword. It would probably give a different bad migrations experience to other users. Is there a way to make CASCADE apply to some object types and not others?

There has been discussion of making view-based models in Django, that would maybe solve it for you in a different way by providing a way to manage views through the migrations framework. What do you think of that?

Thanks,

Adam

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/b21b2791-539f-46e0-a60c-f90c208ca020%40googlegroups.com.

--

Adam