#22620: "Multiple databases" chapter of docs says 'default':{} can start
DATABASES
setting; Django says no
-------------------------------------+-------------------------------------
Reporter: moc@… | Owner: nobody
Type: | Status: new
Cleanup/optimization | Version: 1.6
Component: Documentation | Resolution:
Severity: Normal | Triage Stage:
Keywords: multiple_databases | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by moc@…):
* status: closed => new
* version: 1.5 => 1.6
* resolution: invalid =>
Comment:
I'll deal with the "For n"'s of timo in turn:
"For 1, I don't see an issue as the default database is being used to
store sessions, hence the error. It is possible to configure Django so the
default database isn't used, but you haven't done that."
This about the ticket referring to the fact that the "Multiple databases"
chapter clearly states and shows, with text and code, that you can, if you
need to, start the DATABASES setting with 'default':{}... with an empty
dictionary in place of the parameters for your first database, with
'mydb1':{usual params}, 'mydb2':{usual params} to follow.
So this ticket is of course about how the documentation of the "Multiple
databases" chapter works or fails to work; it's not about how Django
works. And the question is `if after following the instructions and code
example of the 'default':{} approach, how is anyone to know FROM THIS
CHAPTER that there is some other required step with which it "is possible
to configure Django so the default database isn't used"--- that the reader
might thus avoid the error?' Why isn't there an immediate mention of the
need for this other configuration step, right next to the code example for
the empty 'default' dictionary approach?
Perhaps a core developer can read the provided traceback, which pertains
entirely to django internals, and immediately know what to do. But we do
not acquire and use frameworks so that we can learn all of the source code
and how it works.
On to the next For...
"For 2, I believe your initial interpretation is correct (there's the
reference to "synchronizing these three models"). I think it'll be safer
not to change this text."
Yes the ticket is nit-picky on that one, as it admits, but note especially
that it says that I tested deleting ALL of the objects from my second
database other than the tables from the models from one of my apps, the
only app that uses the second database--- not just those three objects.
There are no resultant problems. I did the deleting using "manage.py
dbshell --database=mydb2", which opens the default sqlite2 database
manager which allows me, with a ".tables" command to clearly see all of
the tables and with SQL DROP statements to delete any one of them. Not
only am I able to read and write to the two databases separately through
views in different apps but I have implemented a "class
MultiDBModelAdmin(admin.ModelAdmin):" and "class
Mydb2AdminSite(AdminSite):" as advised in this chapter so as to have
separate admin pages for each database--- and that works fine with all of
the objects that are discussed in
https://docs.djangoproject.com/en/1.6/topics/db/multi-db/#behavior-of-
contrib-apps deleted from mydb2, not with just the three deleted. So maybe
my initial interpretation is not correct. My test rather strongly suggests
that it is not.
And now for the last For...
"For 3, I think the best approach is to use the --database flag to
syncdb. Note that syncdb is replaced by migrate in 1.7 and this command
doesn't have a similar flag, so I guess the approach will be different
there."
About the latter tip, be advised that
https://docs.djangoproject.com/en/1.7/topics/db/multi-db/#synchronizing-
your-databases clearly shows a --database flag in use with migrate.
However, timo is probably right about its demise because whereas
https://docs.djangoproject.com/en/1.6/ref/django-admin/#syncdb shows the
--database option https://docs.djangoproject.com/en/1.7/ref/django-admin
/#django-admin-migrate does not. Something has to give there in one or the
other of those chapters. Basically "I guess the approach will be different
there" will have to be replaced by an actual approach.
About "the best approach is to use the --database flag to syncdb",
strangely, the entire https://docs.djangoproject.com/en/1.6/topics/db
/multi-db/#behavior-of-contrib-apps is offered in contradiction of the
earlier https://docs.djangoproject.com/en/1.6/topics/db/multi-db
/#synchronizing-your-databases section, which introduces the use of the
--database flag with syncdb. In that earlier section it clearly states
that:
"to synchronize all models onto all databases in our example (this is with
the 'default' value of DATABASES containing a parameter dictionary, not
empty), you would need to call:
$ ./manage.py syncdb
$ ./manage.py syncdb --database=users"
So it says that all models will go into all databases with this "--
database flag to syncdb" recommendation. But that's precisely what
behavior-of-contrib-apps tells us to avoid in part. My experience has been
that those two syncs indeed put not only the three objects into each
database but also most of the others mentioned in behavior-of-contrib-
apps. Here's a cut a paste from an sqlite3 database manager terminal:
auth_group django_admin_log
auth_group_permissions django_content_type
auth_permission django_session
auth_user django_site
auth_user_groups ...
auth_user_user_permissions <plus my own apps' tables>
So syncdb --database=mydb2 isn't going to avoid the inclusion of any
superfluous objects, hence the ticket's (timo-rejected) suggestion of
referring to the "fine-grained" approach of synchronizing-your-databases
that uses sqlall piped to dbshell.
-Mike
--
Ticket URL: <https://code.djangoproject.com/ticket/22620#comment:3>
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 unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/071.077ea536ca0b069b3f5e894511d41216%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
