On 12/01/2010 08:04 AM, Waldemar Kornewald wrote:
In the end JOINs will be a rather complicated solution. I thought
that's why you wanted to extend the ORM directly to handle embedded
fields in a special way. That should be easier and cleaner.
That's what I'm up to, but I have to know how to reverse engineer
.filter calls from the where tree, anyway.
The changes currently involved are (in django/db/models/sql/query.py):
Line 1022:
try:
... = self.setup_joins(...)
except MultiJoin, e:
...
+ except PseudoJoin, e:
+ e.field.handle_join(self, parts, alias, lookup_type, value)
+ return
Line 1339:
if pos != len(names) - 1:
+ if hasattr(field, 'handle_join'):
+ raise PseudoJoin(field)
if pos == len(names) - 2:
...
The problem now of course is that the alias tables are not changed in
any way so the same alias is reused in each call to 'handle_join'.
I couldn't figure out what exactly I have to with that load of alias and
join tables - I found the code way too complicated, in particular
because if I got it right it's not unusual that aliases are "freed"
every now and then and so on.
So this is where I'm asking the Django devs to give me an advice (or,
even better, a copy-and-paste-ready solution :-) on how to correctly
decide which alias to use. (I already figured out how to make the alias
be different for each 'add_filter' call, but obviously that's not what I
need).
Thanks!
Jonas
--
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.
