Multiple filters with identical patterns: does this make sense?

[trantor]

Hello @tstack (sorry, I am pestering you way too much ;) ).
I was thinking about automating with custom views and filters the launch of lnav for specific purposes, something I would place in the hand of operators who need to perform specific types of log analysis: a sort of simplified use of lnav where I would bind commands/scripts to specific key combinations, etc.

I would apply some filters to pre-filter the rows which would then be filtered through SQL: this to allow the operator to easily modify the filters should they need to using the filter editor. I want to avoid filtering the queries with WHERE conditions since they are more complicated for the users.

However I ended up wondering how to apply filters without duplicating, since I might bind their creation to a keybinding which could be pressed multiple times. I wouldn't want tens of identical filters applied. I noticed that one can apply multiple filters with identical patterns, but since the filters do not appear to be chained sequentially (or at least it does not appear so judging from the ui) I believe it would make sense turning the addition of a filter which already exists as for direction and pattern into a no-op of sorts.

What do you think? Is there a reason against that would make it unreasonable/unfeasible?

[tstack]

I would apply some filters to pre-filter the rows which would then be filtered through SQL

I'm not sure what you mean by "filtered through SQL". Can you give an example?

However I ended up wondering how to apply filters without duplicating

The :filter-in and :filter-out commands check for an existing filter with the same pattern and enable it if it was not already enabled. I don't think they create duplicates. Alternatively, you can use the lnav_view_filters table to create the filters. For that, use REPLACE INTO to avoid the constraint error, like so:

;REPLACE INTO lnav_view_filters (view_name, type, pattern) VALUES ('log', 'out', 'basic')

I noticed that one can apply multiple filters with identical patterns

Ah, the filter editor UI allows multiple filters with the same pattern to be created... oops, that should probably be blocked.

[trantor]

Sorry, I assumed there were no constraints since the UI allowed the creation of multiple identical filters. The SQL interface was my initial idea and the one I'll run with. Good to know about the filter creation commands.
By filtering through SQL I mean creating filtered view with WHERE conditions on the log fields baked in. I would rather prefer having filters visible and manageable via the UI.