Greetings,

As part of proposing a patch for a bug I filed (#12180), I ran across  
this ticket, and took the liberty of claiming it.  Since I'm  
relatively new to working on Django code proper, I wanted to start a  
discussion about possible approaches to solving these issues.

I see two basic philosophical approaches:

1. The "safety razor" approach:  Django checks the version of the  
database server software, and either adapts its functionality to it or  
(at least) provides an early and explicit error, even at the cost of  
some performance.

2. The "straight razor" approach:  Django accepts any statements the  
user code makes about the database software at face value, and  
maximizes performance, accepting that the user being wrong will result  
in an obscure error at some random point.

Some specific things I'd like to accomplish:

-- Allow Django to use the INSERT...RETURNING functionality of PG 8.2+  
even if autocommit isn't being used.
-- Get rid of the need to repeatedly call SELECT version().

Some other functionality that's not directly relevant to this ticket,  
but related and useful:

-- Allow for Serializable transactions.

Thoughts?
--
-- Christophe Pettus
    x...@thebuild.com

As with all complex questions, the answer is "it depends". In this
case, it depends on exactly what you're asking the database to do, and
what API you're using to do it. I would characterise Django's approach
to database support as the following:

 1. Provide an abstracted, easily explainable API that can be used
across all databases

 2. When a particular API can't be implemented on a particular
database, fallback to a functioning, but downgraded version of
functionality described by the API (e.g., savepoints are a no-op under
MySQL)

 3. When functionality can't be downgraded gracefully, raise
Django-level generic errors early (e.g., Stdev aggregate/annotate
support for SQLite)

 4. Raise system-specific errors as a last resort, or when the end
user has access to internals.

"Obscure random errors" are rarely going to be desirable. It should be
difficult to use the API in the wrong way. If this means we need to
sacrifice a some efficiency in the name of providing a robust API to
end users, then so be it. However, we're also not going to wrap the
entire Django API in cotton wool and bubble wrap just to make sure
that nothing can ever break in an unexpected fashion. If the user is
tinkering with internals in an unusual way, or relying on the
specifics of a particular database, then the user should expect to see
some database-specific errors.

My thought is make a concrete suggestion, and/or "show us the patch" :-)

These issues aren't trivial to solve, and we're certainly open to
anyone that wants to take a serious swing at addressing them. However,
it's much easier to provide design guidance in the specific, rather
than the abstract.

Yours,
Russ Magee %-)