Is it possible to do a

OR

filter on n/search when building the filters array through search.createFilter objects, or do I have to fallback to the old array based structure to handle this?

I wanna say you can... I just can't remember how, the older array structure is just better for readability so I always use that and would recommend everyone should.

I've been using createFilter where possible just in case they decide to deprecate the older methodology at some point. Same with create column.

if you wanna future proof use n/query instead of n/search 😉

Touché. I just had to write SS1 the other day for an email plugin... How did devs of yore not go insane? Is there a perf difference between n/query and n/search?

I'm not aware of a specific performance difference, if anything I'd assume query would have to be faster cos the search is ultimately converted into SQL somewhere else and that step would take time but I'd imagine its marginal

Thankfully most of my hops are 1:1... The only time i have needed a query was when I was pulling assembly component quantities on hand.

They can deprecate but they will not remove it. It will break ALOT of stuff.

It is currently possible to use an OR with search filters, but it requires usage of the undocumented _marshal and _unmarshal methods of a search filter. That doesnt really sound like it matches your goal of compatibility. That said, filter expressions are newer than search filters; search filters are more likely to be deprecated first.

Good to know. Guess I'll eventually work on refactoring my searches to use the filter expressions / queries as time permits.

You don't have to refactor the old ones. They cannot just remove the support for filters.

I'm aware. I prefer keeping things uniform when possible though. It would mainly be a project for when we go and update existing scripts to update them.

throw in my obligatory suggestion to switch to SuiteQL if you can.