I don't think namespacing is a valid objection against query hints. By
design, query hints are specific to a database version and if a
generic django app were to include them, then the author is doing
something wrong or setting the expectation of only supporting a very
specific environment. Any core implementation for supporting this
should be minimalist and only provide a mechanism for passing some
kind of data from the QuerySet to the SQLCompiler that each backend
can optionally choose to do something with it.
I would be thrilled to be able to do use
with_hints('HASH GROUP', 'FAST 10')
and have it set
Query.query_hints = ['HASH GROUP', 'FAST 10']
I'm currently patching in support so I can do something like this for
django-mssql.
Regards,
Michael Manfre
On Jul 22, 12:03 am, Russell Keith-Magee <russ...@keith-magee.com>
wrote:
> On Fri, Jul 16, 2010 at 10:43 AM, Simon Litchfield <si...@slicmedia.com>
> wrote:
> > Russ --
>
> > Firstly, re namespacing. No worries, let's just keep it RDBMS-
> > specific, ie --
>
> > MySQL - with_hints(use={}, force={}, ignore={})
> > Oracle - with_hints(index={}, ...)
>
> > That gives plenty of name space to breathe in.
>
> True, I don't think it's a really nice API. Why is "index" a command
> for Oracle? What happens if some other backend accepts something with
> a "index"? Personally, I'd rather see this be an explicit namespace:
>
> with_hints(mysql={...}, oracle={...})
>
> That guarantees that there isn't any cross-database clashes with hint
> names, only with database backend names. A backend can choose look at
> the full list of hints and determine which hint set it should use;
> potentially, it could even look at another backend's hints and act on
> them (although I don't know why this would be helpful, except perhaps
> in the case of a custom MySQL backend that extends the base
> capabilities).
>
>
>
> > Next --
>
> >> Using the filter/exclude name sounds interesting, but skips the first
> >> step of putting an index hint on the origin table. For example,
> >> Book.objects.filter(author__name='foo') -- now put an index hint on
> >> Book; now put one on Author. If Author and Book are an a m2m relation
> >> -- put a hint on the m2m table.
>
> > How about --
>
> > {'book': 'book_idx', 'author': 'author_idx', 'author__name':
> > 'm2m_idx'}
>
> > Or, if you want to cover absolutely every possibility --
>
> > {'book': 'book_idx', 'author__name__author': 'author_idx',
> > 'author__name': 'm2m_idx'}
>
> > That is, require indexes on the right side of joins to be named
> > explicitly, just in case Author is used in another join.
>
> > Sounds complicated, but obviously edge case. Common usage will be
> > simple, eg {'book':'book_idx'}.
>
> > Let me know what you think.
>
> What about when the query constructs multiple joins on a related
> table? How does the hint get named and applied then? Is it a
> consistent "a join between A and B will always get hint X"? Or do
> different joins need different hints?
>
> 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-develop...@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.
