[wp-trac] [WordPress Trac] #33341: WP_Meta_Query IN operator with empty array does not return expected result

[WordPress Trac]

#33341: WP_Meta_Query IN operator with empty array does not return expected result
--------------------------+------------------------------
 Reporter:  flixos90      |       Owner:  (none)
     Type:  defect (bug)  |      Status:  reopened
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Query         |     Version:  3.2
 Severity:  critical      |  Resolution:
 Keywords:  dev-feedback  |     Focuses:
--------------------------+------------------------------

Comment (by epeleg):

 17 months (or 8 Years) later and this bug is still Awaiting Review.

 I don't see how this makes sense in any way.

 when someone ends up discovering this bug it is not difficult to fix (but
 it might very well be that the developer would not discover the bug but it
 will show up with the users.

 I can see how in some scenarios it might make sense to have this semantics
 in A UI,
 like consider having a list of objects with a shape and color properties,
 and the UI asks you what colors you want to choose and you check RED and
 BLUE to limit to show only RED and BLUE than not checking any color (i.e.
 having the group of checked items empty) would mean that you do not want
 to filter and you want to return all the object regardless of their color.

 BUT this does not make sense when writing code. none of the shapes has a
 color that is a IN an empty group of color names.

 I would claim that the expected behavior would be that even if the shape
 has a null value, its value not IN an empty array of values and it would
 require an array with an element that is null to return the posts that
 have null in said field.

 I doubt that there is lots of code that relays on this odd behavior - had
 I written such a UI as I described above I would probably make sure that
 if no colors where selected I would not add a limiting IN with an empty
 array.

 This should be fixed. IMHO if a developer in the past expected IN {} to be
 true for all it would make more sense for his code to fail that for that
 of any future developers that would exped IN {} to be false...

 At the minimum this should be highlighted in the docs and possibly some
 warning and an option to explicitly opt-in to one of the two behaviors
 could be added.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/33341#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform