[MXS-3394] "Rewrite Filter" Created: 2021-02-02  Updated: 2022-08-22  Resolved: 2022-08-16

Status: Closed
Project: MariaDB MaxScale
Component/s: rewritefilter
Affects Version/s: None
Fix Version/s: 22.08.0

Type: New Feature Priority: Major
Reporter: Johan Wikman Assignee: Niclas Antti
Resolution: Fixed Votes: 1
Labels: None

Sprint: MXS-SPRINT-156, MXS-SPRINT-157, MXS-SPRINT-158, MXS-SPRINT-159, MXS-SPRINT-160, MXS-SPRINT-162, MXS-SPRINT-163, MXS-SPRINT-164

 Description   

There are statements that are expensive to perform but that can be optimized, yet are not optimized by the server. In some cases such statements can not only be identified by a regular expression, but also rewritten by one.

The primary driver of the rewriting filter is to provide a mechanism using which DBAs can provide regular expressions that rewrite statements, so that their execution by the server is faster.

It should be noted that rewriting anything with regular expression is very fragile, as it is easy to create something that matches when it shouldn't and that does not match when it should, so as a tool it is quite blunt.

It shall be possible

  • to provide an arbitrary number of ordered regular expressions that are applied on all statements passing through MaxScale, and
  • to change at runtime the list of expressions.

However, note that the list of expressions are fixed at session creation time. Changes take effect only on sessions created after the changes have been made.

It should be possible:

  • to specify whether the expressions are applied until first match or whether subsequent expressions should be applied to the altered statement.

This sounds a bit like Named Server Filter and Regex Filter; why not extend either of those? There are a number of reasons why that is not feasible.

  • Creating the boiler plate of a filter is trivial, so not having to do that saves nothing.
  • Both of those filters have their complete configuration in the configuration file, which is not only clumsy and fragile, but not applicable if the number of regular expressions can be large and if they must be modifiable at runtime.
  • As what is described here is different from what either of those filters are directly intended for, there would have to be different modes and the filter would have to behave differently depending on the mode it is running in. That would add complexity and the risk for the old behaviour breaking would be quite high.

Generated at Thu Feb 08 04:21:06 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.