Hello Simon,
I'm going to paste a trimmed-down version of the involved classes:
class CeleryTask(models.Model):
celery_task_id = models.CharField(max_length=50, primary_key=True)
task_type = models.ForeignKey(ContentType)
task_id = models.PositiveIntegerField()
task = GenericForeignKey('task_type', 'task_id')
class AccountManagementTask(models.Model):
account = models.ForeignKey(Account, null=True, editable=False)
task_content_type = models.ForeignKey(ContentType)
task_content_id = models.PositiveIntegerField()
task_content = GenericForeignKey('task_content_type', 'task_content_id')
celery_task = GenericRelation(CeleryTask,
content_type_field='task_type', object_id_field='task_id',
related_query_name='account_management_tasks')
(the task_content thing is involved in a follow-up question that will be
asked in a short while)
This is the code triggering the weirdness:
previous_tasks =
AccountManagementTask.objects.filter(account=account)\
.prefetch_related(
Prefetch('celery_task',
to_attr='celery_task'))\
.prefetch_related(
Prefetch('task_content',
to_attr='task_content'))\
.annotate(created_on=F('celery_task__created_on'))\
Immediately after that, the QuerySet is sent off to a simple DRF serializer
- which doesn't even touch the issue since the relevant piece of
information is annotated:
class AccountManagementTaskSerializer(serializers.ModelSerializer):
def to_representation(self, instance):
return {'id': instance.pk,
'created_on': instance.created_on,
'date_from': instance.task_content.date_from,
'date_to': instance.task_content.date_to}
class Meta:
model = AccountManagementTask
Now the follow-up, that you might already have guessed: if I *do* use the
same name for following the GenericForeignKey relation (task_content), the
content of the relationship does not get deleted(no surprise there..?) and
I can go with my naïve serialization over there, while if I specify a
different to_attr name I get back a list and I have to deal differently
with that.
How do these prefetch_related / Prefetch to_attr / Generic* things really
work?
Merci beaucoup,
Michele
On Thu, Nov 5, 2015 at 4:14 PM, Simon Charette <charett...@gmail.com> wrote:
> Hi mccc,
>
> Would it be possible to provide an example of the models and actions
> required to trigger the deletion.
>
> I suppose the deletion is triggered by the many to many relationship
> assignment logic and we should simply raise a ValueError if `to_attr` is
> set the same name as the referred relationship.
>
> Thanks,
> Simon
>
> Le jeudi 5 novembre 2015 15:04:31 UTC+1, mccc a écrit :
>>
>> I'm using a Prefetch object to follow some GenericRelation, and I was
>> playing around with the to_attr parameter;
>> I had the DB debug turned on, as I was checking whether it was making any
>> difference, and I started noticing some DELETE statements on the remote
>> table, so I started investigating.
>> It looks like those deletions are triggered within the prefetch process
>> when the to_attr is set to the same name as the field; also, it does not
>> seem to happen if the relationship is not a generic one.
>> While this usage is presumably wrong, it is not mentioned anywhere in the
>> docs; also, I think that deleting rows from the database is a somewhat
>> extreme way to educate users :)
>> Can someone enlighten me on what's going on here?
>>
>> Thank you very much.
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-users/CDe4McxxCsI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/3a9eae38-e532-4c28-be04-61b5b62ed030%40googlegroups.com
> <https://groups.google.com/d/msgid/django-users/3a9eae38-e532-4c28-be04-61b5b62ed030%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> 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+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/CAP1Jri%2BmP7OCeK2fSKepEDAWvJ8U8C1ATZdv2RCTs48WBgk3OA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
