I think the SQL statement creation for the case of 
matching a string property to a list of values is 
wrong. In rdbms_common.py, in the method Class.filter, 
the statement (line 2105 in version 0.85)
where.append('(' +' and '.join(["_%s._%s LIKE '%s'"%
(cn, k, s) for s in v])+')')
 
should be 
where.append('(' +' or '.join(["_%s._%s LIKE '%s'"%
(cn, k, s) for s in v])+')')

as the documentations suggest:
The filter must match all properties specificed - but 
if the property value to match is a list, any one of 
the values in the list may match for that property to 
match.

Best regards,
George

Logged In: YES 
user_id=6405

Whoops. Meant to say "rejected". 
 
It is rejected because the current behaviour is correct 
though the docstring is incorrect. I will amend the doc. 

Logged In: YES 
user_id=464497

I dont't want to argue about the corectness of the 
behaviour, although I maintain my position. The issue is 
not of corectness but of usefulness. What use is to match a 
property against a list of values in an 'and' fashion. For 
example, given a value of 1,2 what property can match the 
value 1 and 2. The condition will be always false. Matching 
1 or 2 is both correct and useful.
By the way how do you filter a property to have a value of 
either 1 or 2 ?

Logged In: YES 
user_id=464497

I dont't want to argue about the corectness of the 
behaviour, although I maintain my position. The issue is 
not of corectness but of usefulness. What use is to match a 
property against a list of values in an 'and' fashion. For 
example, given a value of 1,2 what property can match the 
value 1 and 2. The condition will be always false. Matching 
1 or 2 is both correct and useful.
By the way how do you filter a property to have a value of 
either 1 or 2 ?

Logged In: YES 
user_id=6405

You currently must perform two queries if you wish to  
perform an OR search.  
  
This is a known missing feature. Patches implementing more 
advanced filtering are always appreciated. 
 

Logged In: YES 
user_id=464497

The above patch correctly implements the OR behaviour and 
does not have any problems with backwards compatibiltiy as 
it is almost sure no one was using this feature, because 
the matching with a list of values in an AND mode (value == 
1 and value == 2) always fails. 

Using the OR semantics is useful, simple as a patch, and 
ressembles the Pythonic "value in list" boolean expression.

Of course the NOT opertaor is still missing, but that is 
another issue. 

Logged In: YES 
user_id=6405

But "value=1 and value=2" isn't the use case!  
  
This is a string search, using LIKE clauses. Its use case  
is someone entering "foo bar" and the filter() code  
matching  
  
  like '%foo%' and like '%bar%'