On Wed, Dec 30, 2009 at 6:13 AM, CB <cbw...@gmail.com> wrote: > Hello. > > I've been developing on the multdb branch for awhile now (most recent > version just before the dropping of the 'using' meta attribute), and > everything has been going well. Recently though, with multidb landing > in the trunk, I wanted to switch over to the trunk. > > I have a 'partitioning' scheme somewhat like this: > > ----db_extra > class Building(models.Model): > area = models.ForeignKey('area') > ...etc > > ----default > class Area(models.Model): > ...etc > > > And in db_extra, i've defined a custom manager that overrides > get_query_set(), returning .using('db_extra') as per the svn docs. ... > Am I doing this correctly? How can I inform django to lookup the > foreign key in this db?
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. On databases like Postgres that have referential integrity, this approach will cause referential integrity errors. 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. The intention is to restore these referential integrity checks at some point in the future. We may also need to look at ways of storing cross-database foreign keys to accommodate the sort of use case that you describe. 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-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.