> Oliver, meet ticket #7052. Ticket #7052, meet Oliver :-)\ Thanking you, I'm not as familiar with the tickets as I should be =)
> The best workaround that I can suggest is to include your ContentTypes > in your fixtures. They are dumpable objects, just like everything else > in Django. If your fixture contains the content types, it doesn't > matter what primary key values are automatically created, because they > will be overwritten by the fixture. You shouldn't get any duplicate > primary key errors because the fixtures framework overwrites existing > objects with the same primary key. The only time you need to be > careful is when you start adding new models, and new content types are > created - if you don't update your fixtures, you could get some > interesting side effects. Thanks, I tried this before but for some reason it wasn't working for me (import errors). However, as per your suggestion I tried it again and all was well and good the second time around :) I must have been doing something wrong (or perhaps there's an outdated [pre-1.0] version of Django on my laptop… should check into that). Anyway, I was thinking about this, when it suddenly hit me… why the heck do ContentTypes have automatic IDs as their primary keys, and why the heck do they need their own table anyway? The combination of app name/model name HAS to be unique (and if it isn't then the database table name would have to be different in any event). If I simply went and made a contenttypes replacement which used some sort of app signature (be it app name/model name combination, a hash or something else) then I could in theory cut out the whole round-trip of the additional query/JOIN to get the ContentType at all – that is, if I made it so the GenericForeignKey is not actually a ForeignKey at all, merely a reference parsed by Python, so it can look up the database table itself, and therefore avoid another query. I don't know, perhaps the developers had good reasons at the time to use an auto-id method, and there's a very good chance that I've overlooked something crucial that makes this approach unusable… but off the top of my head I can't think of one. I will investigate =) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
