Chaining .not_ before .or_() drops the negation. .not_.or_("id.eq.1") sends or=(id.eq.1) when it should send not.or=(id.eq.1). You get the opposite rows back with no error.
Checked on current main: .not_.eq() and .not_.in_() correctly produce not.eq / not.in. Only .or_() is wrong. In base_request_builder.py, filter() consumes the negate_next flag, but or_() appends its param directly and never checks it.
Verified against local PostgREST 16.2 that not.or= is valid syntax: or=(id.eq.1) returned row 1, not.or=(id.eq.1) returned everything except row 1.
The not_ docstring says the next filter gets negated, and or_ is a filter. text_search builds params the same direct way so it may have the same problem, but I only verified or_ end to end.
Chaining
.not_before.or_()drops the negation..not_.or_("id.eq.1")sendsor=(id.eq.1)when it should sendnot.or=(id.eq.1). You get the opposite rows back with no error.Checked on current main:
.not_.eq()and.not_.in_()correctly producenot.eq/not.in. Only.or_()is wrong. Inbase_request_builder.py,filter()consumes thenegate_nextflag, butor_()appends its param directly and never checks it.Verified against local PostgREST 16.2 that
not.or=is valid syntax:or=(id.eq.1)returned row 1,not.or=(id.eq.1)returned everything except row 1.The
not_docstring says the next filter gets negated, andor_is a filter.text_searchbuilds params the same direct way so it may have the same problem, but I only verifiedor_end to end.