remove_stale_contenttypes doesn't remove entries for renamed apps.

[gowtham kommineni]

Currently, it only removes content types in scenarios where you either rename a model or delete a model. If I rename an App from "app_label1" to "app_label2", it doesn't delete content types for "app_label1" and this is causing issues where I use ContentType as a GenericForeignKey.

After I renamed an App and ran remove_stale_contenttypes, I had content types like the following:
app_label1_Post
app_label2_Post

app_label1_Comment

app_label2_Comment


My Django ticket was closed saying "I don't think that `remove_stale_contenttypes` should remove content types for nonexistent apps. We don't automatically remove models for nonexistent apps and I don't think we should do this with content types. This can also cause a data loss for custom content types (not related to real apps)."

May be we can add an optional kwarg to remove_stale_contenttypes command to remove all contenttypes that do not have a corresponding model in existing apps. That would allow us to use the standard command with that optional kwarg while allowing others to keep custom contenttypes. Can you please let me how we can add this functionality while respecting others using custom contenttypes.

[Adam Johnson]

Hi Gowtham

My Django ticket was closed

Please link to the ticket here.

May be we can add an optional kwarg to remove_stale_contenttypes command to remove all contenttypes that do not have a corresponding model in existing appsv

That sounds somewhat reasonable to me. I think there are more implications for renaming an app pthough. Wouldn't it be better when renaming an app to add a migration to update the existing ContentType rows to point to the new names? Then existing rows with Generic Foreign Key should continue to work?

--
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/c306cc5d-4eeb-4324-b210-7017f9269293%40googlegroups.com.

--

Adam

[gowtham kommineni]

Hi Adam

Please link to the ticket here.

ticket: https://code.djangoproject.com/ticket/31123
PR: https://github.com/django/django/pull/12257 

[Adam Johnson]

Mariusz makes the point on the ticket that this can cause data loss for custom content types, which is true.

This seems to be a fairly thorny problem to me since there are several different data loss risks. Perhaps a documentation change would be the easiest first step - one can always remove particular stale content types in a data migration.

--

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/e27e1fd5-9ba9-4b9d-b9a0-f477fb353769%40googlegroups.com.

--

Adam

[Javier Buzzi]

@adam I agree with your points, about data loss, but this can still see this as being beneficial, perhaps the approach was just too harsh. Perhaps adding a flag in the management command would get everyone on board? The flag being off by default and only turns on if you know what you’re doing and enable it. At any rate i believe from what i can i see in the code it will still prompt you to delete the items it finds unless you added the ——no—input which prevents helps with data loss.

[Adam Johnson]

I guess an optional kwarg would be okay then.

On Thu, 2 Jan 2020 at 03:08, Javier Buzzi <buzzi....@gmail.com> wrote:

@adam I agree with your points, about data loss, but this can still see this as being beneficial, perhaps the approach was just too harsh. Perhaps adding a flag in the management command would get everyone on board? The flag being off by default and only turns on if you know what you’re doing and enable it. At any rate i believe from what i can i see in the code it will still prompt you to delete the items it finds unless you added the ——no—input which prevents helps with data loss.

--
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/5c55fdaa-8d89-4baa-a08d-68b0e84c610c%40googlegroups.com.

--

Adam

[Jon Dufresne]

An optional command line argument makes sense to me. +1

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

[Javier Buzzi]

Hey guys, looks like gowtham added  a new PR, can you guys add some insight?

https://github.com/django/django/pull/12558
https://code.djangoproject.com/ticket/31123

The question of what to call the flag that will add this functionality has come up, I'm hoping one of you has a better name.

Thanks.

On Saturday, January 4, 2020 at 12:00:11 PM UTC-5, Jon Dufresne wrote:

An optional command line argument makes sense to me. +1

On Thu, Jan 2, 2020 at 2:11 PM Adam Johnson <m...@adamj.eu> wrote:

I guess an optional kwarg would be okay then.

On Thu, 2 Jan 2020 at 03:08, Javier Buzzi <buzzi...@gmail.com> wrote:

@adam I agree with your points, about data loss, but this can still see this as being beneficial, perhaps the approach was just too harsh. Perhaps adding a flag in the management command would get everyone on board? The flag being off by default and only turns on if you know what you’re doing and enable it. At any rate i believe from what i can i see in the code it will still prompt you to delete the items it finds unless you added the ——no—input which prevents helps with data loss.

--
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-d...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5c55fdaa-8d89-4baa-a08d-68b0e84c610c%40googlegroups.com.

--

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-d...@googlegroups.com.