Thank you, Michal,

Unfortunately, I need join condition, not a WHERE clause, which can be
easily extended with extra() method arguments.
It is not my bad mood, simply the same condition in WHERE and ON
produces different effect.

I think rather about some method which gets together whole SQL query.
Currently I call join() on queryset's query to join my table with part
of target join condition.
I could take the query assembled by "assembler" method and replace the
part of condition with an entire one.

It seems you know pretty much about Django ORM if you work on
composite keys (great respect).
Could you please hint me about this "assembler" method I babble about?

Alexander.

On 30 июн, 23:55, Michal Petrucha <michal.petru...@ksp.sk> wrote:
> On Thu, Jun 30, 2011 at 08:19:36AM -0700, peroksid wrote:
> > Hi.
>
> > Queryset attribute query has method join() which allows to explicitly
> > make JOINs. First argument passed to this method is a tuple of left
> > table, right table, left column and right column, and rest of
> > arguments define if we have LEFT OUTER or INNER join. Arguments from
> > the tuple are used to create an "ON" expression like
> > left_table.left_column=right_table.right_column.
>
> > I need to have for the "ON" expression slighlty more complex
> > expression, something like
> > "left_table.left_column=right_table.right_column AND
> > right_table.another_column=42". Method join() obviously  can not be
> > used for this purpose because it tuple defining join connection
> > consists off 4 elements.
> > I suspect there is no way to create such a double join condition at
> > all, event without constant involved instead of column.
>
> > Tinkering with query does not promise anything here.
> > I could be happy with replacing a part of resulting SQL query before
> > it is sent to the database.
> > Is there a way to filter text of SQL query somewhere before it is
> > executed?
>
> I hope you realize this is deep ORM black magic you're messing with.
> (-:
>
> Anyway, as for your problem, if the query is otherwise simple enough
> that you can know for sure what alias "right_table" gets, you can
> hijack this using QuerySet.extra to add a filter on this table.
>
> Another idea might be to look at the implementation of
> GenericForeignKeys. You'll notice a method, extra_filters, which is
> used in reverse generic relation traversals. This is used to add a
> very similar extra filter to a join, in this case limiting the query
> to a single content type.
>
> To use this feature, you'd have to create a subclass of the field used
> by right_table.right_column to implement this. Then a regular lookup
> spanning this field (assuming it is a relationship field) would
> trigger its extra_filters. Note however, this is pretty much limited,
> you'd probably have to apply a fair bit of logic inside this method
> (unless this kind of join is the only one you want to make on this
> field) and is subject to change. More specifically, it is still
> possible I'll have to modify its behavior as part of my work on
> composite fields.
>
> Anyway, should you use either possibility, the extra filter won't be
> part of the join condition, rather it will appear in the WHERE clause.
> That shouldn't matter much, though.
>
> Hope this will help you.
>
> Michal
>
>  signature.asc
> < 1KбПросмотретьЗагрузить

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

Reply via email to