#16039: syncdb with --database option fails
-------------------------------------+-------------------------------------
Reporter: yedpodtrzitko | Owner: nobody
Type: Bug | Status: new
Component: Database layer | Version: 1.4
(models, ORM) | Resolution:
Severity: Release blocker | Triage Stage: Design
Keywords: | decision needed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by russellm):
Replying to [comment:21 akaariai]:
> Yes, leaving master/slave out of this ticket seems like a good idea.
>
> So, currently even if `ContentTypes` and `Permissions` are installed to
each database by default, the data isn't created by syncdb to 'other'.
Actually, the default is populated by doing a `manage.py syncdb
--database=other`. This seems wrong - the default DB should not be touched
at all if syncing 'other'.
>
> So, here is a simplified suggestion for this ticket:
There is another option, which I raised on IRC over the weekend but didn't
fully endorse at the time; however, I've had a bit of a chance to think
about it now, and I think it's work looking into some more.
Don't make any special cases here, don't worry about master/slaving
contenttypes, and so on; treat each database as a completely separate
concern. If contenttypes is marked to be synchronized onto a database,
then you populate that database with the contenttypes values for models
synchronized onto that database.
The default routing strategy is "everything synchronizes everywhere", so
this means that a content type for every model will be created on every
database.
A more subtle routing strategy might allow the model Foo to only be
synchronized on 'other'. This would mean no content type for Foo on
'default', but there would be one on 'other'.
The upshot of this approach is that all the Generic FK issues that have
been reported with multi-db get resolved. It also means the patch that has
been provided is pretty much ready to go,
The complication is that any given content type won't have a unique PK
across all databases. Contenttypes would be guaranteed complete and
accurate on any given database, but a content type would only be available
if the model was synchronized on that database. However, you can't join
across databases anyway; all this means is that if you want to simulate a
cross-database join, you need to do a lookup on the remote database for
the comparable foreign key.
You'll also need to be careful when doing queries against the contenttype
table to make sure you're getting the "right" contenttype from the "right"
database. A default ContentType.objects.get() call won't hit the right
database without providing context. However, any attempt to use a
contenttype from the wrong database should raise a cross-database error,
so while this will be an annoying detail to get right all the time, it is
something that should be easy to debug.
--
Ticket URL: <https://code.djangoproject.com/ticket/16039#comment:23>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
