#32332: Relation with non-auto CharField primary key is not correctly persisted
if
the primary key is defined after assignment
-------------------------------------+-------------------------------------
Reporter: Charlie DeTar | Owner: nobody
Type: Bug | Status: new
Component: Database layer | Version: 3.1
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Description changed by Charlie DeTar:
Old description:
> Given a model with a foreign key relation to another model that has a
> non-auto CharField as its primary key:
>
> {{{
> class Product(models.Model):
> sku = models.CharField(primary_key=True, max_length=50)
>
> class Order(models.Model):
> product = models.ForeignKey(Product, on_delete=models.CASCADE)
> }}}
>
> If the relation is initialized on the parent with an empty instance that
> does not yet specify its primary key, and the primary key is subsequently
> defined, the parent does not "see" the primary key's change:
>
> {{{
> with transaction.atomic():
> order = Order()
> order.product = Product()
> order.product.sku = "foo"
> order.product.save()
> order.save()
>
> assert Order.objects.filter(product_id="").exists() # Succeeds, but
> shouldn't
> assert Order.objects.filter(product=order.product).exists() # Fails
> }}}
>
> Instead of `product_id` being populated with `product.sku`, it is set to
> emptystring. The foreign key constraint which would enforce the
> existence of a product with `sku=""` is deferred until the transaction
> commits. The transaction does correctly fail on commit with a
> `ForeignKeyViolation` due to the non-existence of a product with
> emptystring as its primary key.
>
> On the other hand, if the related unsaved instance is initialized with
> its primary key before assignment to the parent, it is persisted
> correctly:
> {{{
> with transaction.atomic():
> order = Order()
> order.product = Product(sku="foo")
> order.product.save()
> order.save()
>
> assert Order.objects.filter(product=product).exists() # succeeds
> }}}
>
> Committing the transaction also succeeds.
>
> This may have something to do with how the `Order.product_id` field is
> handled at assignment, together with something about handling fetching of
> auto vs non-auto primary keys from the related instance.
New description:
Given a model with a foreign key relation to another model that has a non-
auto CharField as its primary key:
{{{
class Product(models.Model):
sku = models.CharField(primary_key=True, max_length=50)
class Order(models.Model):
product = models.ForeignKey(Product, on_delete=models.CASCADE)
}}}
If the relation is initialized on the parent with an empty instance that
does not yet specify its primary key, and the primary key is subsequently
defined, the parent does not "see" the primary key's change:
{{{
with transaction.atomic():
order = Order()
order.product = Product()
order.product.sku = "foo"
order.product.save()
order.save()
assert Order.objects.filter(product_id="").exists() # Succeeds, but
shouldn't
assert Order.objects.filter(product=order.product).exists() # Fails
}}}
Instead of `product_id` being populated with `product.sku`, it is set to
emptystring. The foreign key constraint which would enforce the existence
of a product with `sku=""` is deferred until the transaction commits. The
transaction does correctly fail on commit with a `ForeignKeyViolation` due
to the non-existence of a product with emptystring as its primary key.
On the other hand, if the related unsaved instance is initialized with its
primary key before assignment to the parent, it is persisted correctly:
{{{
with transaction.atomic():
order = Order()
order.product = Product(sku="foo")
order.product.save()
order.save()
assert Order.objects.filter(product=order.product).exists() #
succeeds
}}}
Committing the transaction also succeeds.
This may have something to do with how the `Order.product_id` field is
handled at assignment, together with something about handling fetching of
auto vs non-auto primary keys from the related instance.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/32332#comment:1>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/066.6a7b1ad95eafc7477ba1f52bb28b293a%40djangoproject.com.
