Fwd on discussion regarding the "in" operator

View: New views
1 Messages — Rating Filter:   Alert me  

Fwd on discussion regarding the "in" operator

by Carl Michael Skog :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hello there all.
This is a discussion between me and Manuel about the new "in" operator
Manuel implemented.
Please join the discussion.
======================================================================
Hello,

I was hoping that you could repost this message in the list and I could
reply to it there so everybody is aware. Since you didn't post it there,
I am replying to you directly.

on 02/09/2006 09:53 PM Carl Michael Skog said the following:

> Hi there !
>
> Thanks for implementing the "in" operator.
> However, I found a slight bug...
> I have two classes(tabArt and tabCarModel) that are
> related(collections CarModels and Articles) by a many-to-many
> relation.
> If I use the "in" operator in a report function, to find the tabArt's
> that are related to a tabCarModel, I get following condition in the
> generated function:
> 'theArticles.id=t.tabArt_CarModels AND
t.tabCarModel_Articles=theCarModel.id'
>
> That is tabArt_CarModels and tabCarModel_Articles should be switched:
> 'theArticles.id=t.tabCarModel_Articles AND
t.tabArt_CarModels=theCarModel.id'
>
> Patch included.

That looks like what is expected. Can you send me a minimal extract of
your project component with those to classes and the report class query
and function you are using so I can verify it ASAP?


> Interesting is also to filter on which objects is NOT in a collection.
> Applying the 'not' operator on the 'in' operator leads to following
> condition (same conditions as above except the not operator applied).
> 'NOT (theArticles.id=t.tabCarModel_Articles AND
> t.tabArt_CarModels=theCarModel.id)'
> That is a simple 'NOT' added around the equijoin.
> This is, of course, very wrong(the Cartesian product except the number
> of related objects).

Right, negating the join clauses does not seem to be what you want. I
think it would be better to have a <notin /> operator that would
generate the correct SQL.

If I am not mistaken not in would correctly implemented with a NOT IN
SQL clause followd by a sub-select right? I am not sure if this would be
the best method.








 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/metal-dev/

<*> To unsubscribe from this group, send an email to:
    metal-dev-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 



LightInTheBox - Buy quality products at wholesale price