Many thanks. I am using MySQL with InnoDB, as a matter of fact. When
I installed MySQL that's what it recommended.
Your suggestion works fine. I was trying Person as a subclass of
User, and couldn't get that
to initialize.
On Jan 3, 4:55 am, "Russell Keith-Magee" <freakboy3...@gmail.com>
wrote:
> On Sat, Jan 3, 2009 at 3:01 AM, adrian <adrian...@gmail.com> wrote:
>
> > I happen to have a bunch of models that all haveforeignkeys, but
> > there is an order in which they could all be initialized. I have
> > figured out how to initialize the built-in User model usingJsondata,
> > but I can't initialize any models that refer to it using aforeign
> >key. Is this possible and if so how?
>
> Yes, it is possible. If you have a model something like:
>
> class Person(Model):
> user = ForeignKey(User)
> name = CharField(...)
>
> this will serialize something like:
>
> {
> "model": "myapp.person',
> "pk": 1,
> "fields": {
> "user": 3,
> "name": "Fred"
> }
>
> }
>
> The reference to a user is just the primarykeyof the object you want
> to refer to. If you want a more comprehensive example using your own
> models, try creating some instances using the Python API, then use the
> manage.py dumpdata command to produce sample fixtures.
>
> Generally speaking, you don't need to worry about the order of
> initialization. In your fixture, you can define the Person then the
> User, or the User and then the Person - it doesn't matter.
>
> If you're using SQLite or MySQL with MyISAM tables, there is no
> referential integrity to worry about, so you can create a Person that
> refers to a User that doesn't exist yet. As long as you eventually
> create the User, you won't have any problems.
>
> If you're using Postgres, all the fixtures are loaded in a
> transaction, and referential integrity isn't checked until the end of
> the transaction. As long as the Person and the User are both loaded at
> the end of fixture loading, the order in which they are created
> doesn't matter.
>
> The only exception to this rule is MySQL with InnoDB tables - which,
> because of its retarted referential integrity, insists on checking
> references at the end of every commit, rather than at the end of the
> transactional block. This means that you have to manually check that
> the fixture with an ordering such that the User is loaded before the
> Person.
>
> Until MySQL fixes its referential integrity rules for InnoDB, this
> limitation can't be avoided in the general case. Any form of circular
> reference between models will always pose difficulties - there is no
> way to provide an ordering that is guaranteed to load successfully.
>
> Yours,
> Russ Magee %-)
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
