ForeignKey to a model in another database

187 weergaven
Naar het eerste ongelezen bericht

Pieter Swinkels

ongelezen,
24 nov 2010, 07:07:4924-11-2010
aan South Users
Currently I am working on a project that uses multiple Django apps
with multiple databases. I have a problem that seems to be caused by
the following construct: model M from application A and database D has
a ForeignKey to model N from application B and database E. When
South’s test runner integration creates the test database via
migrations, I get an error that looks like this:

south DEBUG south execute "ALTER TABLE "A_M" ADD CONSTRAINT
"volume_id_refs_tkey_5eb09669" FOREIGN KEY ("volume_id") REFERENCES
"N" ("tkey") DEFERRABLE INITIALLY DEFERRED;" with params "[]"
...
django.db.utils.DatabaseError: relation "B_N" does not exist

So South tries to create the ForeignKey from M to N in the same
database, viz. database D. I understand that what South tries to do
fails, as the table for model N is not present in database D. But am I
using South incorrectly or is this a limitation of South? I have
googled for answers but nothing that quite matches the problem I
encounter. For your information, I use Django 1.2.3 and South 0.7.2.

I know that I can workaround this problem using the
SOUTH_TESTS_MIGRATE setting. However, my colleagues will encounter
similar problems when they want to recreate the databases from scratch.

Andrew Godwin

ongelezen,
29 nov 2010, 05:41:4129-11-2010
aan south...@googlegroups.com
On 24/11/10 12:07, Pieter Swinkels wrote:
> Currently I am working on a project that uses multiple Django apps
> with multiple databases. I have a problem that seems to be caused by
> the following construct: model M from application A and database D has
> a ForeignKey to model N from application B and database E. When
> South�s test runner integration creates the test database via

> migrations, I get an error that looks like this:
>
> south DEBUG south execute "ALTER TABLE "A_M" ADD CONSTRAINT
> "volume_id_refs_tkey_5eb09669" FOREIGN KEY ("volume_id") REFERENCES
> "N" ("tkey") DEFERRABLE INITIALLY DEFERRED;" with params "[]"
> ...
> django.db.utils.DatabaseError: relation "B_N" does not exist
>
> So South tries to create the ForeignKey from M to N in the same
> database, viz. database D. I understand that what South tries to do
> fails, as the table for model N is not present in database D. But am I
> using South incorrectly or is this a limitation of South? I have
> googled for answers but nothing that quite matches the problem I
> encounter. For your information, I use Django 1.2.3 and South 0.7.2.
>
> I know that I can workaround this problem using the
> SOUTH_TESTS_MIGRATE setting. However, my colleagues will encounter
> similar problems when they want to recreate the databases from scratch.

Well, the problem here is that, generally, ForeignKeys across multiple
databases isn't possible, and so I'm not likely to support it soon.
South's multiple database support is limited at best at the moment, and
this is only possible using MySQL with both databases the same host, so
there's other more pressing issues we need to solve first.

Andrew

Pieter Swinkels

ongelezen,
3 dec 2010, 03:37:0003-12-2010
aan South Users
On 29 nov, 11:41, Andrew Godwin <and...@aeracode.org> wrote:
> On 24/11/10 12:07, Pieter Swinkels wrote:
> > I have a problem that seems to be caused by
> > the following construct: model M from application A and database D has
> > a ForeignKey to model N from application B and database E. When
> > South s test runner integration creates the test database via
> > migrations, I get an error
>
> Well, the problem here is that, generally, ForeignKeys across multiple
> databases isn't possible, and so I'm not likely to support it soon.

First of all, thank you for your reply. Now I know it is not something
trivial I have to change to make it work. I have a workaround for the
problem which makes using South a bit more cumbersome. But that is
only a minor issue.

Back to your reply, ForeignKeys across multiple database is possible
in Django. I have an app that uses a PostgreSQL database with foreign
keys to a SQLite database. Maybe on a database level these
relationships do not exist and it is Django that makes it appear to me
these ForeignKeys exist. But as I am using Django, I do not mind :)

Pieter.

Sindre Myren

ongelezen,
3 dec 2010, 06:02:1403-12-2010
aan south...@googlegroups.com
2010/12/3 Pieter Swinkels <pieter....@nelen-schuurmans.nl>:
> --
> You received this message because you are subscribed to the Google Groups "South Users" group.
> To post to this group, send email to south...@googlegroups.com.
> To unsubscribe from this group, send email to south-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/south-users?hl=en.
>
>
I think Django just creates an IntegerField at the database level. If
you manually change the forward/bacward migration to create an
IntegerField instead of a ForeignKey - if app a and app b is not in
the same database that is - It might work.

I guess this could be done at the South level (if someone created a
patch for it), but as Andrew says, it is not high priority, so it
might be easier to fix it in your migration instead.

--
Sindre

Andrew Godwin

ongelezen,
3 dec 2010, 06:07:3403-12-2010
aan south...@googlegroups.com

I'm... very impressed they're working at the Django level. I'll have to
look into it (there must be a whole new, inefficient query-running
system for those - cross-database joins are one of the most inefficient
operations ever).

Still, considering I've never heard of this before, and because it's a
really, really crazy schema, it's still low priority. As Sindre says,
just make the raw field types either end rather than a ForeignKey field
type for now.

Andrew

Pieter Swinkels

ongelezen,
9 dec 2010, 06:40:4109-12-2010
aan South Users
On 3 dec, 09:37, Pieter Swinkels <pieter.swink...@nelen-schuurmans.nl>
wrote:
> First of all, thank you for your reply. Now I know it is not something
> trivial I have to change to make it work. I have a workaround for the
> problem which makes using South a bit more cumbersome. But that is
> only a minor issue.

A colleague of mine mentioned it would be nice if I would explain the
workaround in this thread. He's right: I also do not like it if I find
posts that mention a workaround without giving the workaround. So here
is what I did to be able to recreate the database from scratch:
1. Disable South's test runner integration: set the option
SOUTH_TESTS_MIGRATE in settings.py to False
2. Disable South in you Django project: remove 'south' from the tuple
of installed apps (in settings.py)
3. Create the database using Django's syncdb: bin/django syncdb
4. Enable South: add 'south' to the tuple of installed apps (in
settings.py)
5. Fake the migration up to the last step: bin/django migrate <app> --
fake
That's it.

Allen beantwoorden
Auteur beantwoorden
Doorsturen
0 nieuwe berichten