Simon --
Slicing result sets is clearly the developer's responsibility IMHO.
Even with hard limits, MySQL still fails miserably in many situations;
hence the proposal to support hinting from the ORM.
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.
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.
--
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.
