On Jan 30, 12:06 pm, Oliver Beattie <oli...@obeattie.com> wrote:
> > 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 =)
I have been doing some work on this. The code is available at
http://github.com/ericholscher/sandbox/blob/d32da8c36f257bb973a5c0b0fd8f9bca79062f11/serializers/yamlfk.py
if you want to look. There aren't any tests yet or anything, but it
worksforme.
It currently works by looking at the FK your model points to and
seeing if it has any unique constaints. If it does, it turns the
fixture into a dict that contains kwargs that will refer to that
unique constraint. So this works for content types, yielding a fixture
something like:
- fields:
content_type: {app_label: weblogs, model: entry}
name: Favorite blog entry
On the load, it simply runs this query and passes the pk of the object
it finds in.
It doesn't currently work for foreignkeys that refer to foreignkeys,
and things with no unique constraints. (Perhaps making a --slug-is-
unique setting or something, where it will use slugs as a query.
Currently they aren't guarenteed to be unique would be really useful
in a lot of cases.)
Cheers,
Eric
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
