On Nov 30, 9:34 pm, "Jonas H." <jo...@lophus.org> wrote: > Hello List! > > I'm working on queries on embedded objects for Django-nonrel (more > precisely, djangotoolbox) that will use JOIN-like syntax. > > For this, I need to know how to distinguish > .filter(spam__op=eggs, foo__op=bar) > from > .filter(spam__op=eggs).filter(foo__op=bar) > > in the .where tree used in django.db.models.sql.query.Query. > > My first idea was to guess the original query expression from the where > tree's structure, but I suspect that will work out for all kinds of > queries (using Q objects in particular). > > So -- is it possible? How do the SQL backends decide when to do one JOIN > with two SELECTs or two JOINS with one SELECT each?
You can take a look at django-dbindexer. It can rewrite JOINs such that they become simple filter calls on the main model. It's part of our automatic denormalization / JOIN emulation code. We haven't yet announced this because the current implementation isn't complete, but it's sufficient if you want to understand how JOINs work. However, you'll also have to change the embedded field, so it behaves like a ForeignKey. Otherwise the ORM won't generate a JOIN for it. 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. BTW, what were Alex' results regarding embedded objects? Did you discuss any design/implementation ideas? Bye, Waldemar -- 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.
