[NoSQL] Sub-object queries / refactoring JOIN syntax into model fields

[Jonas H.]

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

[Florian Apolloner]

On Wednesday, September 28, 2011 12:52:51 AM UTC+2, jo...@lophus.org wrote:

What's the core team's opinion on this topic -- is there any chance to

Secondly, how could this be implemented?

Did you search the mailing list about this topic at all yet? I am not sure, but I think Alex implemented something like that in the NoSQL branch.

Cheers,
Florian

[Jonas H.]

No, there's no such thing in Alex' GSoC branch.

[Kääriäinen Anssi]

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: django-d...@googlegroups.com [django-d...@googlegroups.com] On Behalf Of Jonas H. [jo...@lophus.org]
Sent: Wednesday, September 28, 2011 01:52
To: django-developers
Subject: [NoSQL] Sub-object queries / refactoring JOIN syntax into model fields

Hallöchen,

Vote.objects.filter(votes__vote__gt=2)
...

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 django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

[Jonas H.]

bump