On Sat, Nov 7, 2009 at 12:50 PM, Christophe Pettus <x...@thebuild.com> wrote: > > 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.
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. > 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? 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 %-) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
