You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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:
$
match_method
enum-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.
The text was updated successfully, but these errors were encountered: