#25265: DB Backend cannot specify query class.
-------------------------------------+-------------------------------------
Reporter: techdragon | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by techdragon):
RE: akaariai
--
The situation between 'comparable' database backends should actually be
more like what will happen if you did the same query
{{{User.objects.filter(id=10).using('postgres')}}} with a MySQL and
PostgreSQL backend. I can't say I've done that myself, but if it raises an
error, it should raise an error between a sql and a nonsql backend.
'Non comparable' backends should probably raise an error, something like
{{{NotImplemented}}} perhaps.
--
RE: jarshwah
--
1 - This offers little improvement over a custom model that uses the Meta
API, and overrides the save method.
2 - This is more like what I'm thinking. While its definitely possible to
enhance the flexibility by providing a SETTINGS powered override, I'm not
sure that defining the 'default' query for any particular backend in the
SETTINGS dictionary is the right way to go.
3 - Just like suggestion 1, this doesn't improve the 'compatibility'
situation significantly, beyond what can be done with existing mechanisms
such as custom models using the Meta API and overriding their save
methods.
--
Ideally with a database backend that supports all the correct methods, we
should be able to run Django entirely on top of it, so that means either
extensive modifications to contrib.user and other contrib modules, to
support some kind of 'optional non sql path', or we need to 'fix' the
'issues' that currently exist with this and related section of code that
result in the public API to the ORM mandating that any Django database
backend behave like an SQL database.
I'm fairly sure the optimal path is shifting some of this back into the
database backend 'layer'. Possibly creating a new "base_sql" class that
the existing SQL database backends inherit from instead of
{{{db.backends.base}}} and things like defining 'what is my query class'
can be set here and shared by all the SQL backends. Otherwise we just
implement the new behaviour in each backend.
--
Ticket URL: <https://code.djangoproject.com/ticket/25265#comment:3>
Django <https://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 unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/068.5d6738e351dbce6f6d65c4a9bb925b6d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
