Allowing non delete cascading
3 views
Skip to first unread message
Manuel Saelices
Feb 15, 2009, 7:03:34 PM2/15/09
to Django developers
In one of my Django projects, customer accidentally deleted related
objects because django-batchadmin doesn't advice for related objects
deletion. The question was I thought Django would not delete related
objects in a nullable many to one relation, but Django in fact deleted
it (of course, according to documentation).
Customer uses admin for site administration and I think is not usable
that in a usual object -> category nullable relation he have to clear
every object related to one category (maybe hundreds of them) to
remove the category itself.
Then, I searched into docs and internet for a solution to my problem,
and the options were:
1) Use a many to many relation. This is not viable... ¿why I have to
change a good data model into a not real model to get it work? In UML
there are two kinds of many to one relations: aggregations and
compositions. Objects in a aggregation can exists independently of his
parent object.
2) Clear related objects before deleting (with objects.clear() ), but
it doesn't work for a default django admin site.
These are the reasons to think in a possible improvement in Django
ORM. I've patched django to support a model like this:
class Master(models.Model):
pass
class Slave(models.Model):
master = models.ForeignKey(Master, null=True, delete_cascade=False)
Independently in notation i've used, I think this concept can be
useful in a lot of Django web sites.
I've created a ticket for this and attached a patch with unit tests.
This ticket was marked into "Design decision needed" stage by a
triager, and this is the reason I post this.
Ticket is this:
http://code.djangoproject.com/ticket/10262
If other developers accept this ticket (maybe with another notation),
I compromise to work on this.
Regards,
Manuel Saelices
objects because django-batchadmin doesn't advice for related objects
deletion. The question was I thought Django would not delete related
objects in a nullable many to one relation, but Django in fact deleted
it (of course, according to documentation).
Customer uses admin for site administration and I think is not usable
that in a usual object -> category nullable relation he have to clear
every object related to one category (maybe hundreds of them) to
remove the category itself.
Then, I searched into docs and internet for a solution to my problem,
and the options were:
1) Use a many to many relation. This is not viable... ¿why I have to
change a good data model into a not real model to get it work? In UML
there are two kinds of many to one relations: aggregations and
compositions. Objects in a aggregation can exists independently of his
parent object.
2) Clear related objects before deleting (with objects.clear() ), but
it doesn't work for a default django admin site.
These are the reasons to think in a possible improvement in Django
ORM. I've patched django to support a model like this:
class Master(models.Model):
pass
class Slave(models.Model):
master = models.ForeignKey(Master, null=True, delete_cascade=False)
Independently in notation i've used, I think this concept can be
useful in a lot of Django web sites.
I've created a ticket for this and attached a patch with unit tests.
This ticket was marked into "Design decision needed" stage by a
triager, and this is the reason I post this.
Ticket is this:
http://code.djangoproject.com/ticket/10262
If other developers accept this ticket (maybe with another notation),
I compromise to work on this.
Regards,
Manuel Saelices
Karen Tracey
Feb 15, 2009, 7:28:31 PM2/15/09
to django-d...@googlegroups.com
On Sun, Feb 15, 2009 at 7:03 PM, Manuel Saelices <msae...@gmail.com> wrote:
[snip background]
This has come up before, see:
http://code.djangoproject.com/ticket/2288
That one was closed wontfix with a statement that pre-delete signals should be able to handle this job. If they don't they need to be fixed. #6108 looks to be open as a follow-up to that.
Is there anything new/different about this proposal than #2288? If not, step one is going to have to be to convince Jacob that the wontfix on the original ticket asking for this should be revisited. Until then I don't see a new proposal for the same thing going anywhere, and I'd recommend focusing on getting the recommended alternative working instead (unless there is some flaw in that, which would probably be a good reason to revisit the first wontfix...but I haven' t seen anyone say there is a flaw in the alternative, just some support -- possibly including design of that support -- that hasn't been implemented yet?).
Karen
[snip background]
These are the reasons to think in a possible improvement in Django
ORM. I've patched django to support a model like this:
class Master(models.Model):
pass
class Slave(models.Model):
master = models.ForeignKey(Master, null=True, delete_cascade=False)
Independently in notation i've used, I think this concept can be
useful in a lot of Django web sites.
I've created a ticket for this and attached a patch with unit tests.
This ticket was marked into "Design decision needed" stage by a
triager, and this is the reason I post this.
Ticket is this:
http://code.djangoproject.com/ticket/10262
If other developers accept this ticket (maybe with another notation),
I compromise to work on this.
This has come up before, see:
http://code.djangoproject.com/ticket/2288
That one was closed wontfix with a statement that pre-delete signals should be able to handle this job. If they don't they need to be fixed. #6108 looks to be open as a follow-up to that.
Is there anything new/different about this proposal than #2288? If not, step one is going to have to be to convince Jacob that the wontfix on the original ticket asking for this should be revisited. Until then I don't see a new proposal for the same thing going anywhere, and I'd recommend focusing on getting the recommended alternative working instead (unless there is some flaw in that, which would probably be a good reason to revisit the first wontfix...but I haven' t seen anyone say there is a flaw in the alternative, just some support -- possibly including design of that support -- that hasn't been implemented yet?).
Karen
Manuel Saelices
Feb 15, 2009, 7:54:36 PM2/15/09
to Django developers
On 16 feb, 01:28, Karen Tracey <kmtra...@gmail.com> wrote:
> On Sun, Feb 15, 2009 at 7:03 PM, Manuel Saelices <msaeli...@gmail.com>wrote:
> [snip background]
>
>
>
> > These are the reasons to think in a possible improvement in Django
> > ORM. I've patched django to support a model like this:
>
> > class Master(models.Model):
> > pass
>
> > class Slave(models.Model):
> > master = models.ForeignKey(Master, null=True, delete_cascade=False)
>
> > Independently in notation i've used, I think this concept can be
> > useful in a lot of Django web sites.
>
> > I've created a ticket for this and attached a patch with unit tests.
> > This ticket was marked into "Design decision needed" stage by a
> > triager, and this is the reason I post this.
>
> > Ticket is this:
>
> > http://code.djangoproject.com/ticket/10262
>
> > If other developers accept this ticket (maybe with another notation),
> > I compromise to work on this.
>
> This has come up before, see:
>
> http://code.djangoproject.com/ticket/2288
>
> That one was closed wontfix with a statement that pre-delete signals should
> be able to handle this job. If they don't they need to be fixed. #6108
> looks to be open as a follow-up to that.
>
> Is there anything new/different about this proposal than #2288?
There are a main difference: #10262 solution doesn't intend relying in
> [snip background]
>
>
>
> > These are the reasons to think in a possible improvement in Django
> > ORM. I've patched django to support a model like this:
>
> > class Master(models.Model):
> > pass
>
> > class Slave(models.Model):
> > master = models.ForeignKey(Master, null=True, delete_cascade=False)
>
> > Independently in notation i've used, I think this concept can be
> > useful in a lot of Django web sites.
>
> > I've created a ticket for this and attached a patch with unit tests.
> > This ticket was marked into "Design decision needed" stage by a
> > triager, and this is the reason I post this.
>
> > Ticket is this:
>
> > http://code.djangoproject.com/ticket/10262
>
> > If other developers accept this ticket (maybe with another notation),
> > I compromise to work on this.
>
> This has come up before, see:
>
> http://code.djangoproject.com/ticket/2288
>
> That one was closed wontfix with a statement that pre-delete signals should
> be able to handle this job. If they don't they need to be fixed. #6108
> looks to be open as a follow-up to that.
>
> Is there anything new/different about this proposal than #2288?
database DELETE CASCADE features. It uses Django mechanism to collect
objects to be deleted, and it will call to delete method on those (and
emit signals too).
And with respect #6108 ticket, this ticket is an all or nothing
solution. I only can stop deletion by raising an error if I don't like
collected objects that would be deleted, but for example I can't
change this object list to another I like.
Thing is I think Django ORM should implement relations between objects
where usually one object must live independently the other. Ticket is
not about DELETE CASCADE... is about modelling relations [1].
Regards
[1] http://ootips.org/uml-hasa.html
Michael Glassford
Feb 16, 2009, 8:47:56 AM2/16/09
to django-d...@googlegroups.com
Don't forget http://code.djangoproject.com/ticket/7539. The patch is
old--it's for Django 0.96--so it needs to be updated. Hopefully I'll
manage to do this in the next week or two as we start moving our project
from 0.96 to 1.0.x. But it to handles ON CASCADE DELETE / RESTRICT
SET NULL behavior either in the db or in Django, at the developer's
discretion.
Mike
old--it's for Django 0.96--so it needs to be updated. Hopefully I'll
manage to do this in the next week or two as we start moving our project
from 0.96 to 1.0.x. But it to handles ON CASCADE DELETE / RESTRICT
SET NULL behavior either in the db or in Django, at the developer's
discretion.
Mike
Michael Glassford
Feb 16, 2009, 8:47:56 AM2/16/09
to public-django-developer...@hugh.gmane.org
Don't forget http://code.djangoproject.com/ticket/7539. The patch is
old--it's for Django 0.96--so it needs to be updated. Hopefully I'll
manage to do this in the next week or two as we start moving our project
from 0.96 to 1.0.x. But it to handles ON CASCADE DELETE / RESTRICT
SET NULL behavior either in the db or in Django, at the developer's
discretion.
Mike
Manuel Saelices wrote:
>
>
Reply all
Reply to author
Forward
0 new messages