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.
