Hello again,
I have implemented the in_() method which works great for all the
'normal' fields, but throws recursion errors when trying to deal with
the relation to another entity.
Cutting it down to one line:
# print
in_() is not normally implemented for relation()s. I think the
recursion overflow on in_() was a bug at some point which has since
been fixed (and it raises NotImplementedError instead), but I'm not
able to isolate at the moment if it was fixed for the 0.4 series or not.
On May 28, 2008,
Ah, apologies Michael - I should have mentioned that I am using the
svn 0.5 checkout.
In 0.4 it does raise NotImplementedError.
In 0.5 it causes a recursion error.
I understand that the working copy will be more susceptible to bugs
etc so please take this as a note rather than a major issue.
In
at its most simplistic level, IN is just a bunch of X=Y joined
together via OR. Can that approach work here ? (seems like it would
be the best way considering its polymorphic scalar elements being
compared). At a higher level, seems like you'd want to group elements
of common types
Hi Michael,
Thank you for the quick response. I had thought about using a
straightforward OR statement - are you suggesting that this would form
the body of the in_() method on the Comparator or were you referring
more to just compiling the OR statements in the base query?
Also, what is the
On May 27, 2008, at 3:11 PM, Martin Pengelly-Phillips wrote:
Hi Michael,
Thank you for the quick response. I had thought about using a
straightforward OR statement - are you suggesting that this would form
the body of the in_() method on the Comparator or were you referring
more to just
That makes sense - thanks again.
Martin
On May 27, 9:09 pm, Michael Bayer [EMAIL PROTECTED] wrote:
On May 27, 2008, at 3:11 PM, Martin Pengelly-Phillips wrote:
Hi Michael,
Thank you for the quick response. I had thought about using a
straightforward OR statement - are you
