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.
