Is your feature request related to a problem? Please describe.
Currently the only URL path matching mechanism is prefix-based, like e.g. having an active banner for every path starting with /deposit, which matches /deposit, /deposit/123, /deposit/123/info, etc.
For very specific matching (e.g. only for a specific record), this could cause unwanted matches. E.g. if the path is /record/123, then also /record/1234 would be matched.
Describe the solution you'd like
Having a configurable matching mode for each path, would solve this issue. There are a couple of options for implementing this:
- Some "regex"-like matching with
$
- Adding a new
match_method enum-like column to the table, allowing various types of matching (prefix-based, exact, etc.)
- Having a config-based matching function (e.g.
BANNERS_PATH_MATCHER), which allows easy overriding and customized logic.
In general, any solution should also take into account performance implications for fetching active banners, especially in cases where there are multiple active banners in the same period, but for many different paths. E.g. currently the matching logic is performed on the Python side, instead of it being delegated to the SQL query.
Is your feature request related to a problem? Please describe.
Currently the only URL path matching mechanism is prefix-based, like e.g. having an active banner for every path starting with
/deposit, which matches/deposit,/deposit/123,/deposit/123/info, etc.For very specific matching (e.g. only for a specific record), this could cause unwanted matches. E.g. if the path is
/record/123, then also/record/1234would be matched.Describe the solution you'd like
Having a configurable matching mode for each path, would solve this issue. There are a couple of options for implementing this:
$match_methodenum-like column to the table, allowing various types of matching (prefix-based, exact, etc.)BANNERS_PATH_MATCHER), which allows easy overriding and customized logic.In general, any solution should also take into account performance implications for fetching active banners, especially in cases where there are multiple active banners in the same period, but for many different paths. E.g. currently the matching logic is performed on the Python side, instead of it being delegated to the SQL query.