On Apr 25, 7:11 am, Alex Gaynor <alex.gay...@gmail.com> wrote: > Simon uses a new DSN based syntax for specifying DBs, however I find this > pretty akward in the presence of our existing way for defining DB settings.
I had a few reasons for suggesting DSNs: * We already use DSN-style syntax for cache backends - it's weird to do it there (for something that isn't actually a database) but not for our database settings. Of course, that inconsistency could be fixed by splitting up the settings for cache backends instead. * SQLObject and SQLAchemy both use DSNs. * If we implement my suggestion that a using() method can take a connection object OR a connection alias string (defined in settings.py) OR a DSN, it's much easier to dynamically construct a database connection at runtime. I'm particularly interested in that last usage scenario. Personally I'm not a big fan of settings.py - over the past four years I've found myself at various times wanting to dynamically alter almost every setting in there - and there are some interesting edge cases where creating a database connection at run time could be useful. Three off the top of my head: 1. A phpMyAdmin style application for administering remote databases, which might allow the user to enter their database details in to an online form 2. A web-based installation mechanism, such as the one used by WordPress 3. (really nutty one this) - a very high scale situation where an application is partitioned across hundreds of databases, which each one having the same set of tables. This is how WordPress-MU works (as used by wordpress.com), with every blog getting its own duplicate set of tables - and it's surprisingly effective. Creating a database connection at runtime doesn't require DSNs of course, provided you can feed your own connection object to any using () clause rather than being tied to using connections that have already been configured in settings.py. > Further a DSN method removes the presence of something like > DATABASE_OPTIONS(unless we start adding query strings onto the end), which > is very useful for things like the postgresql auto commit option, plus I > plan to move the TEST_DATABSE_* settings into DATABASE_OPTIONS, since things > like charset are DB dependent. Again, we use query strings for cache backends so I have no problem with using them for database options. I wouldn't be heartbroken if DSNs weren't used in Django, but the above should at least explain the reasons behind my suggestion. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
