#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 aaugustin):
After discussing with Anssi on IRC and reviewing the history of this
ticket, I have two concrete proposals:
'''(1) All content types and permissions are synced to the target database
(with or without the `--database` option) unless the routers prevent it.
That is, if `allow_syncdb` returns `True` or `None`, they're sync'd, if it
returns `False`, they aren't.'''
(2) Use the same rule as 1) for the default database; for non-default
databases sync all content types and permissions only if the routers
mandate it. That is, if `allow_syncdb` returns `True`, they're sync'd, if
it returns `False` or `None`, they aren't.
Both rules are compatible with the philosophy of the routers.
Option (2) biases Django towards having a single copy of the content types
and permissions in the default table, reducing the likelyhood of the id
mismatch problem. But it's harder to implement, document and to explain,
and I don't have any strong arguments supporting it. Also, I suspect it
won't solve the reporter's problem: without any routers, syncing
django.contrib.auth to a non-default database will still fail. So I have a
weak preference for option (1).
In addition, for users who wish to run syncdb on more than one database,
we should recommend to define routers that allow syncing the contenttypes
and permissions tables only to one database, to avoid the pk mismatch
problem. I don't expect many people to attempt this anyway. Most multi-db
users will:
- have a master / slave setup: they run `syncdb` once to master, and the
replication takes care of the rest;
- have a master database for Django itself, and interact with existing
external databases, most likely with unmanaged models;
- or a combination of both.
----
It seems to me that Russell's proposal to split content types across
databases doesn't work as is. The admin's permissions have a foreign key
to content types; therefore all content types need to be available in a
table in the same database that holds the admin's permissions table.
(Actually that's what Anssi says in the comment just above, which I read
after writing this.) If we want to investigate this option further, let's
split it to another ticket, because it isn't a release blocker.
--
Ticket URL: <https://code.djangoproject.com/ticket/16039#comment:26>
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.
