On Mon, Aug 20, 2007 at 03:13:52PM +1000, Malcolm Tredinnick wrote: > > On Sun, 2007-08-19 at 23:01 -0500, Adrian Holovaty wrote: > [...] > > I haven't yet made DatabaseError, IntegrityError and the introspection > > and creation functionality accessible via the django.db.connection > > object. Those changes can happen in the near future, if they need to > > be made. > > If we do move those (not clear why it would be needed, though),
Ironically, it's kind of core to why I did the refactoring, and I covered it already in the original email (cons 3 & 4) :) Expanding a bit, intention was to cleanup access for multidb crap, and to enable simple wrappers to be generated/used. Think through whats required to wrap a random backend (say mysql) right now; you have to have either 1) a bunch of crappy one line modules importing from the actual target (if you're doing it right, it checks a global to know which backend to wrap, or if you're in a hurry you wind up with seperate persistant-mysql and persistant-sqlite backends ;) 2) fun code that does module creation/injection via sys.modules Both routes kind of suck in a single connection environment; that said, both routes are *unusable* in multidb. Think it through- if the two backends are mysql, hey hey, same exception, lucky you. What if the backends are mysql and pgsql, and you need to catch the mysql db exceptions? [1] Basically, from django.db import connection, IntegrityError, DatabaseError try: connection.do_something except (IntegrityError, DatabaseError): pass vs from django.db import connection try: connection.do_something except (connection.IntegrityError, connection.DatabaseError): pass The latter localizes the exception class to the connection itself- more importantly, it allows (in a true mdb env) for passing around a namespace for accessing that *specific* connection, not trying to catch an exception from a non-default db/cursor with the default dbs exception classes (as is the attempted case for mdb branch). That ought to lay out the logic for why localizing the specifics of each connection implementation *to* the connection object itself is needed. [1]: while one could point at multidb branch's django.db.DatabaseError as contradicting this, please verify that code works- that code tries to catch exception x (class A) with class B, with no relation between the two exception classes aside from a common ancestor class; the localizing bits in that are just noise, see no possible way that could work. > it'd be nice to leave backwards compat references in place. We pull out those > exceptions into a db-neutral namespace because people are using them a > lot. So changing it will have a big impact and leaving an alias in place > is free. Not free; long term price is extracted in feature implementation due to it existing. Simpler/saner solution is to have a DatabaseError/IntegrityError exception class (common) at that location; from there, wrap the exceptions thrown from the underlying backend in it. Sucks that the tb from the backend is truncated, but realistically that info can be stored if needs be (rarely is there much info anyways, since it usually terminates in cpy code). Mind you I'm talking about just the exceptions; the misc ops, etc, generally think they should be shift over, and code should migrate to accessing the sub-namespaces from the actual connection object. So... unless folks either don't want that functionality, or can poke large holes through my args above, it's needed. One thing I would like folded in from the v2 patch however is the support for accessing backends from locations other then django.db.backends.* (not required, but the collapsing the namespace onto the connection object helps this)- mainly, I don't think it's a good practice to require folks to monkeypatch stuff into django when they want to use custom backends. Still need to go through and do the backends cleanup/refactoring, but probably won't get to it till this weekend- depending on feedback from this email, may include the chunks of my v2 that were left out also. thanks, ~harring
pgpZGVvjMTK8N.pgp
Description: PGP signature
