"If the concept of a default database doesn’t make sense in the context of your project, you need to be careful to always specify the database that you want to use. Django requires that a default database entry be defined, but the parameters dictionary can be left blank if it will not be used."

I include the traceback just to show that nothing originated in code of mine. Now previously, and now in fact (I switched back), I have my project up and running fine with two databases and with the 'default' key value being the dictionary of parameters for the first database. So I have reason to suggest that perhaps the docs are wrong concerning the possibility of starting with 'default':{}. Maybe it's a legacy thing that is no longer viable.

If I could move on to another item on that very page... this is nit-picky I know but some of us are like that. Sorry. I'm talking about some lines at the very end of the page:

"For common setups with multiple databases, it isn’t useful to have these objects in more than one database... Therefore, it’s recommended:

either to run syncdb only for the default database;
..."

After reading it several times I concluded that by "these objects" was meant only the objects of the preceding paragraph, which include only Site, ContentType and Permission objects. However, I have just experimented and found that dropping from my second database all of the tables associated with ALL of the objects mentioned in the subsection "Behavior of contrib apps" causes no harm.

I therefore suggest that the language there could be clarified. Also, the mentioned option "either to run syncdb only for the default database" could use, say a parenthetic reference to the "$ ./manage.py sqlall sales | ./manage.py dbshell" approach... if that's what you have in mind for syncing the other database.

Thanks for the suggestions. I don't really see any issues with the points you've raised, but feel free to reopen this ticket if you want to provide a patch for anything that could be clarified.

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.

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.

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.

"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."

"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:

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.

I think it's beyond the scope of the documentation to describe how to configure Django without a default database (and I imagine it's not a very common use case), but we could add a note that with the default settings of storing sessions in the DB, it won't work.

I guess some improvements need to be made with respect to 2 and 3, though it seems rather complicated. I look forward to reviewing a patch if you are able to submit one.

For future reference, it would be better to submit a separate ticket for each individual issue, thanks.

For (1), I added a sentence about using DATABASE_ROUTERS to avoid any queries to the default database if you want to run without one.

For (2), I added a similar sentence about using routers to avoid creating tables where you don't want them, but avoided any specific recommendation as I think it's best to let users figure out what tables they want and where.

For (3), after further investigation, migrate does support the --database flag and as far as I could tell the documentation is accurate with respect to how it works.

Note that for apps with migrations sqlall is replaced by sqlmigrate. Given the complexity of migrations, it seems like a bad idea to recommend that as a "fine-grained" approach the way sqlall was, so I removed that suggestion.