Django

Code

Ticket #13941 (closed: fixed)

Opened 2 months ago

Last modified 1 month ago

importing fixtures to postgres fails to set sequences correctly

Reported by: ales_zoulek Assigned to: jbronn
Milestone: Component: Database layer (models, ORM)
Version: SVN Keywords: postgres fixture
Cc: Triage Stage: Unreviewed
Has patch: 1 Needs documentation: 0
Needs tests: 0 Patch needs improvement: 0

Description

there seems to be a problem with django postgres backend, when importing data from fixtures. Data are imported correctly, but the sequences for primary keys are set incorrecly on models that have generic.GenericRelation? field. See example:

As a demo, those are just two models with generic relation.

models.py:
----------
from django.db import models
from django.contrib.contenttypes import generic
from django.contrib.contenttypes.models import ContentType


class Tag(models.Model):
   name = models.CharField(max_length=30)
   content_type = models.ForeignKey(ContentType)
   object_id = models.PositiveIntegerField()
   content_object = generic.GenericForeignKey('content_type', 'object_id')


class Post(models.Model):
   name = models.CharField(max_length=30)
   text = models.TextField()
   tags = generic.GenericRelation('blog.Tag')

The loaddata management command calls at the end

connections[DEFAULT_DB_ALIAS].ops.sequence_reset_sql command

to update sq1 sequences. Let's see the result:

./manage shell
-------------------
In [1]: from django.db import DEFAULT_DB_ALIAS, connections
In [2]: from django.core.management.color import no_style
In [3]: from proj.blog.models import Post
In [4]: connections[DEFAULT_DB_ALIAS].ops.sequence_reset_sql(no_style(), [Post])
Out[4]:
['SELECT setval(pg_get_serial_sequence(\'blog_post\',\'id\'),
coalesce(max("id"), 1), max("id") IS NOT null) FROM "blog_post";',
 'SELECT setval(pg_get_serial_sequence(\'blog_post\',\'id\'),
coalesce(max("id"), 1), max("id") IS NOT null) FROM "blog_tag";']

As you can see, the problem is in the last "SELECT". Postgres backend "thinks" that Post.tags is m2m relation with usual m2m sql table and tries to update it's pk sequence. The table is of course non existant and it resets Post.pk sequence to max(Tag.pk), this is obviously incorrect behaviour and results with potential DatabaseErrors? duplicate key on blog_post table. Removing Post.tags and accessing related tags directly works as a workaround, but not very nice and comfotable one..

Attachments

13941.patch (3.5 kB) - added by ales_zoulek on 07/15/10 08:32:28.
patch and tests

Change History

07/15/10 07:00:25 changed by ales_zoulek

  • needs_better_patch changed.
  • needs_tests changed.
  • needs_docs changed.

07/15/10 08:32:28 changed by ales_zoulek

  • attachment 13941.patch added.

patch and tests

07/15/10 09:01:59 changed by ales_zoulek

  • has_patch set to 1.

07/15/10 16:02:09 changed by jbronn

  • owner changed from nobody to jbronn.
  • status changed from new to assigned.

I've confirmed this as a bug. See also #13821.

07/29/10 21:42:36 changed by russellm

  • status changed from assigned to closed.
  • resolution set to fixed.

(In [13449]) Fixed #13941 -- Corrected the way sequence names are reset under Postgres, especially when generic foreign keys are involved. Thanks to Ales Zoulek for the report and patch.


Add/Change #13941 (importing fixtures to postgres fails to set sequences correctly)




Change Properties
Action