I think that lookup separator syntax is definitely the right approach here.
The implementation should modify setup_joins. I think the cleanest approach
would be to detect that the current lookup part leads to a field with subfields
in either this part of the code:
else:
# Non-relation fields.
target = field
break
Or directly after the for loop in setup_joins, around this line:
if pos != len(names) - 1:
In either case you would want to check if the current field supports subfields
and then continue to do the dirty details of actually descending into the
subfields and returning the results to add_filter. I wonder if you would need
additional flag to setup_joins to indicate if subfield queries are allowed, in
case somebody else than add_filters is the caller. That would be only the tenth
parameter...
There is still the question if this should be included in core. I am in no
position to answer that. All I can say a ListField (or ArrayField) would be
useful in SQL land, too.
- Anssi
_____________________________________
From: [email protected] [[email protected]]
On Behalf Of Jonas H. [[email protected]]
Sent: Wednesday, September 28, 2011 01:52
To: django-developers
Subject: [NoSQL] Sub-object queries / refactoring JOIN syntax into model fields
Hallöchen,
some non-relational databases (e.g. MongoDB) have support for
arbitrarily nested objects. To make queries that "reach" into these
sub-objects, the Django-nonrel developers find it appealing to use JOIN
syntax. For instance, if you had this person in your database
{'name': 'Bob', 'address': {'city': 'NY', 'street': 'Wall Street 42'}}
you could find Bob using these queries:
Person.objects.filter(name='Bob')
Person.objects.filter(address__city='NY')
Person.objects.filter(address__street__startswith='Wall')
...
Similarly, sub-objects may be stored in a list, like so:
{
'votes': [
{'voter': 'Bob', 'vote': 42},
{'voter': 'Ann', 'vote': 3.14}}
]
}
Vote.objects.filter(votes__vote__gt=2)
...
These sub-object queries are essential for non-relational databases to
be really useful so this is an important feature.
What's the core team's opinion on this topic -- is there any chance to
get something like that into Django at all? (Maybe you think two
meanings for one syntax cause too much confusion)
Secondly, how could this be implemented? I thought about refactoring
JOIN syntax handling into the model fields (as little logic as required;
refactoring the actual hardcore JOIN generation code seems like an
impossible task for anyone but the original author)... any other ideas?
So far,
Jonas
--
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.
--
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.
