Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#26197 closed New feature (duplicate)

DEFAULT_DB_ALIAS in settings

Reported by: Marcin Nowak Owned by: nobody
Component: Database layer (models, ORM) Version: dev
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

This is a reopened issue based on #21211.

DEFAULT_DB_ALIAS should be configured in settings for better code readability in multi-db projects, where "default" database works as a default .

The default database is aliased "default". When calling using() we must provide name of connection. Passing "default" is not quite readable. I would like to rename "default" to something more precise, clean, readable. I don't want to change behaviour of the Django itself. Just want to rename the alias.

Workaround by making "default" connection empty does not work. Django raises an error when connection is not set. Defining "default" with some sqlite db is a bad idea, because something may write to it and error will not be reported.

Please make DEFAULT_DB_ALIAS configurable in settings.

Change History (8)

comment:1 Changed 7 years ago by Simon Charette

Type: UncategorizedNew feature
Version: 1.9master

comment:2 Changed 7 years ago by Tim Graham

Resolution: duplicate
Status: newclosed

The appropriate course for reopening a "wontfix" ticket is a discussion on the DevelopersMailingList. Please raise your rationale there, thanks!

comment:3 Changed 7 years ago by Marcin Nowak

Tim, I wrote everyting about requirements. They're simple and clean. Think about it a little, thanks!

comment:4 Changed 7 years ago by Tim Graham

Sorry, but I can't unilaterally accept design decisions like this. That's why it needs discussion on the mailing list. For example, the original authors of multi-database support may have considered and rejected the idea. As mentioned on the related ticket, we do our best to avoid new settings so any proposal for that needs a strong justification and a discussion.

comment:5 Changed 7 years ago by Marcin Nowak

Right. But this is not about design. Im not taking about enhancement of multi db support, but just about one setting. I will not discuss on mailing list because it is a waste of time. My suggestions, like a model.reload(), must wait approx 7 years for your agreement. My endless discussions about disabling migrations are next example. And so on...

I would like to make more contributions for Django, including patches and tests, but I can't pass through idea-wall... My English is too bad for this, I think.

So maybe tell me, please, what consequences might be after changing default db alias? How big is risk? Is it worth starting new discussion? I'm not asking about guys you've mentioned.

comment:6 Changed 7 years ago by Tim Graham

I asked Alex Gaynor, the original author of multi-db support and he said, "Probably a bad idea IMO, I think it makes things much more confusing cross-projects and the benefit isn't clear to me. There's no technical reason you can't do it though."

comment:7 Changed 7 years ago by Marcin Nowak

OK. There is no technical reason to do anything. I said what the reason was, and in fact it wasn't technical. Wow. Thanks!

comment:8 Changed 7 years ago by Marcin Nowak

Oh, I forgot one thing. When "default" is not defined, I'm getting a TECHNICAL problem:

raise ImproperlyConfigured("You must define a '%s' database" % DEFAULT_DB_ALIAS)
django.core.exceptions.ImproperlyConfigured: You must define a 'default' database

Please note that I'm not using any kind of *DEFAULT* database, just explicite database A, B, C and so on.

Removal of "default" connection is not possible (because it's a part of Django` db layer design), so I'm asking to rename "default" to "A" or "B" or "C", etc. As you see I have a technical reason - Django won't start without "default" connection defined.


Note: See TracTickets for help on using tickets.
Back to Top