Admin debugging delete

[Mike Dewhirst]

I'm having trouble debugging a failed child record Delete. That is the
Delete [x] checkbox being ticked does not delete the child record.

It is obviously something to do with my bad but I'm not sure where to
start.

Any hints?

Thanks

Mike

[Mike Dewhirst]

Forgot to mention - Django 1.8, Python 2.7 and 3.4, Postgres 9.1 and
9.3, Apache 2.2 and the dev server

I have been digging a little and think this is a javascript initiated
event. I am not comfortable with javascript so my uncertainty has just
doubled.

Thanks very much for any direction

Cheers

Mike

[Andreas Kuhne]

Hi,

Are you working in django admin and using the delete checkbox to delete a child record?

If so, it is not a javascript event, but it is handled by when you save to the parents form (it's a formset with child forms). I would follow where the django code stops executing.

Regards,

Andréas

--
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/5673CFCF.70707%40dewhirst.com.au.

For more options, visit https://groups.google.com/d/optout.

[Mike Dewhirst]

Thanks Andreas - I'll dig deeper!

Cheers

Mike

On 18/12/2015 9:02 PM, Andreas Kuhne wrote:
> Hi,
>
> Are you working in django admin and using the delete checkbox to delete
> a child record?
>
> If so, it is not a javascript event, but it is handled by when you save
> to the parents form (it's a formset with child forms). I would follow
> where the django code stops executing.
>
> Regards,
>

> Andréas

>
> 2015-12-18 10:20 GMT+01:00 Mike Dewhirst <mi...@dewhirst.com.au

> <mailto:mi...@dewhirst.com.au>>:

>
> Forgot to mention - Django 1.8, Python 2.7 and 3.4, Postgres 9.1 and
> 9.3, Apache 2.2 and the dev server
>
> I have been digging a little and think this is a javascript
> initiated event. I am not comfortable with javascript so my
> uncertainty has just doubled.
>
> Thanks very much for any direction
>
> Cheers
>
> Mike
>
> On 17/12/2015 6:41 PM, Mike Dewhirst wrote:
>
> I'm having trouble debugging a failed child record Delete. That
> is the
> Delete [x] checkbox being ticked does not delete the child record.
>
> It is obviously something to do with my bad but I'm not sure
> where to
> start.
>
> Any hints?
>
> Thanks
>
> Mike
>
>
> --
> 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

> <mailto:django-users%2Bunsu...@googlegroups.com>.

> To post to this group, send email to django...@googlegroups.com

> <mailto: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/5673CFCF.70707%40dewhirst.com.au.
>
> 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

> <mailto:django-users...@googlegroups.com>.

> To post to this group, send email to django...@googlegroups.com

> <mailto: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/CALXYUbmbJ%2B-0bATpHDscunyo6r1CwK7KGAEWvTQk9mxpQFpuiA%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-users/CALXYUbmbJ%2B-0bATpHDscunyo6r1CwK7KGAEWvTQk9mxpQFpuiA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Mike Dewhirst]

On 18/12/2015 9:02 PM, Andreas Kuhne wrote:

> Hi,
>
> Are you working in django admin and using the delete checkbox to delete
> a child record?

Yes

>
> If so, it is not a javascript event, but it is handled by when you save
> to the parents form (it's a formset with child forms). I would follow
> where the django code stops executing.

Ok. I think I found the probrlem.

'''
def save_formset(self, request, form, formset, change):
""" this updates the related records when they change """
instances = formset.save(commit=False)
for instance in instances:
instance.modified_by = request.user
instance.save()
formset.save_m2m()
'''

Commenting this method out in admin.py enabled deletion. Assuming saving
the instance prevents deletion, I tried

for instance in instances:
if not instance in self.deleted_objects:
instance.modified_by = request.user
instance.save()

... but that didn't do anything.

Might have to skip adding request.user to modified objects.

Thanks again for any advice

Cheers

Mike





Haven't found it yet but I have a question about django/forms/models.py

748----self.deleted_objects.append(obj)
749----if commit:
750--------obj.delete()


>
> Regards,
>
> Andréas

>
> 2015-12-18 10:20 GMT+01:00 Mike Dewhirst <mi...@dewhirst.com.au

> <mailto:mi...@dewhirst.com.au>>:

>
> Forgot to mention - Django 1.8, Python 2.7 and 3.4, Postgres 9.1 and
> 9.3, Apache 2.2 and the dev server
>
> I have been digging a little and think this is a javascript
> initiated event. I am not comfortable with javascript so my
> uncertainty has just doubled.
>
> Thanks very much for any direction
>
> Cheers
>
> Mike
>
> On 17/12/2015 6:41 PM, Mike Dewhirst wrote:
>
> I'm having trouble debugging a failed child record Delete. That
> is the
> Delete [x] checkbox being ticked does not delete the child record.
>
> It is obviously something to do with my bad but I'm not sure
> where to
> start.
>
> Any hints?
>
> Thanks
>
> Mike
>
>
> --
> 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

> <mailto:django-users%2Bunsu...@googlegroups.com>.

> To post to this group, send email to django...@googlegroups.com

> <mailto: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/5673CFCF.70707%40dewhirst.com.au.
>
> 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

> <mailto:django-users...@googlegroups.com>.

> To post to this group, send email to django...@googlegroups.com

> <mailto: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/CALXYUbmbJ%2B-0bATpHDscunyo6r1CwK7KGAEWvTQk9mxpQFpuiA%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-users/CALXYUbmbJ%2B-0bATpHDscunyo6r1CwK7KGAEWvTQk9mxpQFpuiA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[James Schneider]

>     for instance in instances:
>         if not instance in self.deleted_objects:
>             instance.modified_by = request.user
>             instance.save()
>
> ... but that didn't do anything.

Shouldn't that be:

if instance not in self.deleted_objects:

I haven't tested this, but I think that will end up looking for False (the 'not' applying to 'instance' rather than the 'in' operation) in self.deleted_objects, which means saving would be broken entirely.

-James

[Mike Dewhirst]

On 20/12/2015 4:30 PM, James Schneider wrote:
>
> > Â Â for instance in instances:
> > Â Â Â Â if not instance in self.deleted_objects:
> > Â Â Â Â Â Â instance.modified_by = request.user
> > Â Â Â Â Â Â instance.save()

> >
> > ... but that didn't do anything.
>
> Shouldn't that be:
>
> if instance not in self.deleted_objects:
>
> I haven't tested this, but I think that will end up looking for False
> (the 'not' applying to 'instance' rather than the 'in' operation) in
> self.deleted_objects, which means saving would be broken entirely.

It certainly looks nicer. But it didn't break saving so I assume it
means something like "if not <some expression>" which expression happens
to be "<instance in self.deleted_objects>"

Your way is easier to read so I'll adopt it.

Thanks James


>
> -James

>
> --
> 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
> <mailto:django-users...@googlegroups.com>.
> To post to this group, send email to django...@googlegroups.com
> <mailto: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/CA%2Be%2BciUabE3ZjXaYjZFi7fui6J7%2BXTNLsyoFomOBzVQeWqQvZw%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-users/CA%2Be%2BciUabE3ZjXaYjZFi7fui6J7%2BXTNLsyoFomOBzVQeWqQvZw%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[James Schneider]

I haven't tested this, but I think that will end up looking for False
(the 'not' applying to 'instance' rather than the 'in' operation) in
self.deleted_objects, which means saving would be broken entirely.

It certainly looks nicer. But it didn't break saving so I assume it means something like "if not <some expression>" which expression happens to be "<instance in self.deleted_objects>"

Agreed. And I did finally get a chance to test this in the interpreter with the same result. There's gotta be some implicit action going on that counts the 'in' as a whole expression, and not taking 'instance' as an individual object, because my dusty algebra brain is kicking and saying that without () to sort out the order, the 'not' should apply only to 'instance'. I even looked it up in the docs and 'not x' has a higher operator precedence than 'in', only feeding my confusion. 

 

Your way is easier to read so I'll adopt it.

I've never seen it written out the way you had it, before.

I'll agree with that. ;-D

-James

[Mike Dewhirst]

On 21/12/2015 6:03 PM, James Schneider wrote:
>
> I haven't tested this, but I think that will end up looking for
> False
> (the 'not' applying to 'instance' rather than the 'in' operation) in
> self.deleted_objects, which means saving would be broken entirely.
>
>
> It certainly looks nicer. But it didn't break saving so I assume it
> means something like "if not <some expression>" which expression
> happens to be "<instance in self.deleted_objects>"
>
>
> Agreed. And I did finally get a chance to test this in the interpreter
> with the same result. There's gotta be some implicit action going on
> that counts the 'in' as a whole expression, and not taking 'instance' as
> an individual object, because my dusty algebra brain is kicking and
> saying that without () to sort out the order, the 'not' should apply
> only to 'instance'. I even looked it up in the docs and 'not x' has a

> higher operator precedence than 'in', only feeding my confusion.Â
> Â

>
> Your way is easier to read so I'll adopt it.
>
>
> I've never seen it written out the way you had it, before.
>
> I'll agree with that. ;-D

Now I think about it, I suspect your way (and now my preferred way)
might have been an innovation for Python 3?

M

>
> -James
>
> --
> 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
> <mailto:django-users...@googlegroups.com>.
> To post to this group, send email to django...@googlegroups.com
> <mailto: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/CA%2Be%2BciXJVVTs8gpt1p978qpQNgduGDU582-99bXKo5y2BZVEUQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-users/CA%2Be%2BciXJVVTs8gpt1p978qpQNgduGDU582-99bXKo5y2BZVEUQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[James Schneider]

>
> Now I think about it, I suspect your way (and now my preferred way) might have been an innovation for Python 3?
>
> M

I don't believe so. I didn't look, but I think that syntax goes back <= 2.6. Pretty sure I've used it in 2.4. I know I've been using it in 2.7 for years. As I mentioned, I'd never seen the syntax ordering that you had used in any source code, documentation, or blog post that I can recall, and I'm still a bit confused as to why it works in my head, but that's just one of those things I'll tuck back for a late-night debug session in the future.

Maybe it was a transparent backport from Python 3 at some point?

-James