implement in_() for relations

[Former user]

This would have to build upon the "optimized_compare" logic so that a JOIN would not be needed for the primary use case of a many-to-one check for a set of foreign key identifiers.

[Mike Bayer]

8e08949eb57592f4e3b3c1c8b92ef8935c150df7 commits a NotImplementedError for this operator, which has not been implemented for many-to-one relations.

[Mike Bayer]

restored the inadvertently-removed NotImplementedError plus a test this time in 2c5f3e8397b52b9a52b2fdd0bef7aed77762e410.

[Former user]

Is this tough? This feature would make my life a lot better :)

I can offer a small cash or gift incentive.. A bottle of your favorite tipple, perhaps? [e-mail] if you would like to take it up..

[Mike Bayer]

the basic theory is very simple, at least for many-to-ones, which is probably the only use case I'd want to support. you can do it yourself for simple cases just like:

query(Parent).filter(Parent.child_id.in_([for c in children](c.id)))

but if the foreign key is composite, then it's a huge PITA unless the backend database supports IN on tuples like PG. So perhaps this would raise for systems that don't support that. Starts getting more tedious.

if the join condition on the M2O isn't simple, then it gets hard too. So I'd probably only have this operator work if the many-to-one satisfies the "uses get" test - the m2o can be located by primary key alone. this is information the mappers already know so is a simple boolean flag.

Then you also have all the tests. So with edge cases detected, full tests, documentation, yeah its pretty tedious, half a day usually to make features like these fully polished. The workaround is so simple too.