#10509: Better handling of database version-specific feature initialisation ------------------------------------------+--------------------------------- Reporter: mtredinnick | Owner: nobody Status: new | Milestone: Component: Database layer (models, ORM) | Version: SVN Keywords: | Stage: Unreviewed Has_patch: 0 | ------------------------------------------+--------------------------------- Right now, we have problems such as those mentioned in #10467 (comment 4). If a part of Django wants to use a particular feature that depends on the database version, it needs to first have talked to the database. This breaks in some edge-cases.
Some alternative possibilities are 1. understanding deferred-features, but that looks hard. For example, it's difficult to imagine how "return ID from insert" can work in that fashion without being really ugly code. 2. requiring the settings file to include the version information so we don't have to make the wasteful `SELECT version();` (or equivalent) call for every database connection. It's essentially unchanging information. Anyway, that's a discussion for later (I'll start a thread on django-dev at some point). Opening the ticket to remind me to look at this. -- Ticket URL: <http://code.djangoproject.com/ticket/10509> Django <http://code.djangoproject.com/> The Web framework for perfectionists with deadlines. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django updates" group. To post to this group, send email to django-updates@googlegroups.com To unsubscribe from this group, send email to django-updates+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-updates?hl=en -~----------~----~----~----~------~----~------~--~---
