> In short, you can't (or shouldn't). > > What you're asking the database to do is keep a foreign key value that > is not valid on the database on which it is stored.
Yes, this is true. > The multi-db branch had checks for this sort of referential integrity > until just before the merge; however, these checks were relaxed just > prior to commit in order to allow for multi-db to support master-slave > partitioning - in these situations, a model will appear to be on a > different database alias, but won't be a referential integrity failure > since it is actually the same database. Yeah, i watched these checks go up and then drop out. > We may also need to look at ways of storing > cross-database foreign keys to accommodate the sort of use case that > you describe. What about creating a new set of ForeignKey fields that don't actually do any real foreign key checking? Maybe CrossDBForeignKey, or RelaxedKey? I understand if this is off the timetable for 1.2 (as I can see the dev group is getting ready for freeze, etc) but if I wanted to develop this route, do you have any pointers? Might I be able to simply subclass ForeignKey (or one of it's bases, etc), and more or less lie about the constraint being fulfilled, tell the DB that this is just an int (like IntegerField), and then convince the Query internals to ask for my data seperately (making it not eligible for select_related, for example)? Either way, i'm going to look into this use case myself and try to make it work (in a hopefully not /too/ hacky way) . If you or anyone else has any pointers, please let me know. Thanks, -CB -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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.
