On Thu, Dec 2, 2010 at 5:03 PM, Jonas H. <[email protected]> wrote:
> 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.

You probably don't want to use those aliases. Instead, you should use
a separate alias namespace for
embedded object filters. Otherwise you'll have to deal with the
complex JOIN code in the backend unnecessary. Aliases for embedded
objects could just be simple integers that get incremented for each
field independently with each new filter() call that mentions the
respective field.

BTW, with "__" lookups there's no way to do deep OR lookups on nested
lists of embedded objects:
a__b=[f='bla' OR g='blub']
vs
a=[b__f='bla' OR b__g='blub']
We only have one representation:
filter(a__b__f='bla').filter(a__b__g='blub')
We'd need something like
filter(a__b=Q(f='bla') | Q(g='blub'))
for the first case. Well, not sure how critical this feature is in the
real world and how many NoSQL DBs support that, at all. It's just
something to keep in mind.

Bye,
Waldemar

-- 
Django on App Engine, MongoDB, ...? Browser-side Python? It's open-source:
http://www.allbuttonspressed.com/blog/django

http://www.linkedin.com/in/wkornewald
http://twitter.com/wkornewald

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Reply via email to