Tech Blog

Django Settings in the Database

Django Settings in the Database

Recently updated on

There's been a healthy amount of discussion about how applications should handle settings. As the creator of Mingus pointed out, it's a weird situation. You want anyone to be able to use your application with as little fuss as possible, but at the same time you just need to have at least some settings involved. When I wrote my blog application, YaBa, I had somewhere around ten different settings that users needed to configure. Every setting you add creates a bit more complexity for the end user, adds more to your documentation, and inevitably leads to you have to write yet another unit test. The biggest hitch though is the added complexity. The simpler your application is to use the more people are likely to use it.

One potential answer is to store the settings in the database so that an end user can just configure those via the administration panel. This way they don't have to go digging through the settings.py and you can load the default settings via a json fixture. Most of the complexity for the end user is removed. Tricks like using they localsettings.py trick is good as well, but if your application is a pluggable application then that isn't really applicable. Hence, it would seem that the database is the best idea that remains.

There are a few applications that try to handle this situation:

Django-DBSettings

Django-LiveSettings

Satchmo-LiveSettings

Both LiveSettings applications are from Satchmo, the popular Django based e-commerce application. However, I should note that only Satchmo-LiveSettings actually works out of the box. Django-LiveSettings still has dependencies on Satchmo itself, kind of ironic given its name I suppose. Personally, I ran into a myriad of snags getting either to run smoothly and the documentation wasn't exactly excellent. They're both works in progress though, and that's totally understandable. Django-DBSettings is a bit frustrating because it gets a lot right but lacks a setup.py. The documentation is a bit spotty, but overall it's pretty good. My only complaint with it is that it requires you to define all of your settings in your code. On the whole, that may not seem like a bad thing, right? After all, a new setting is pointless unless you have access to the code.

Well, that's not entirely true. While it does apply to most cases, but there's an outlier I ran into that it doesn't quite cover. If I use something like Django-DBTemplates, then it's plausible that someone in the administration screens might want to add a setting for some simple logic in the templates. I ran into a scenario that works almost exactly like this, where if a user could add a setting manually, I wouldn't have needed any new code whatsoever. I think Django-DBSettings would cover most needs though, if not my specific needs. However, all the options I've ran into do put the settings at a different path than your traditional adminisitration panel, which is something my users may find confusing or at the very least annoying.

On the upside though, these solutions do prevent editing of vital settings such as the database and what have you. They're just not quite fitting of all my needs directly, which becomes problematic. Obviously, I can help out any of the mentioned projects, and likely will at some point. I suppose the hard part is simply deciding which of the projects to help out, or if I should just create a project of my own that fits my specific needs. Whatever the outcome though, it would be nice if there was something that solved these needs that was well accepted in the community. I'd like to have something I can depend on for adding settings for my applications that doesn't always require direct access to settings.py. It would save me effort and it would make users of my applications happier. The question of the day is simply, how do you do it? There are a myriad of implementation possibilities, but which is right/best? It's certainly a tough call. What has everyone else been doing in this situation?

Comments

Comments are closed.