refactor: extract the standard variable replacement logic into its own class.

[cecilycarver]

Background for this change: the functionality in _replace_variables_middleware is useful in other contexts for standardizing some of the sql functions in a query. Pulling it into its own class so other repos can use it. Should not change any functionality in mysql-mimic.

[barakalon]

Should we also move the "set var" middleware here?

[cecilycarver]

Should we also move the "set var" middleware here?

A little tricky with the saved state, but extracted some of it

[barakalon]

Some bike shedding comments, hopefully thats not too annoying. Feel free to push back on anything.

[barakalon]

Another nit, because I think this is a good opportunity to dig into python style:

SessionContext is like an interface that the VariableProcessor owns (a la dependency inversion).

And we're expecting VariableProcessor to be used in a context that isn't associated with a Session instance.

So maybe we should make this SessionContext interface narrower and easier to use?

For example, perhaps we shouldn't depend on Variables, but rather a generic collections.abc.Mapping[str, Any]? And the Variables class should implement the Mapping protocol?

And maybe fields like "external_user" and "version" should have sensible defaults? I.e. maybe external_user should default to current_user?

Furthermore, python has duck typing. So maybe this doesn't need to be a dataclass? Rather, maybe it should be a Protocol? And the Session instance can implement that protocol and just pass itself in as the SessionContext, instead of instantiating a SessionContext instance?

[cecilycarver]

I guess my question here is that the reason we're trying to encapsulate this logic, as I understand it, isn't just the process of mapping functions in the query to various literals — it's the mapping itself that we want to share between projects, knowledge of how to handle and genericize things like CURDATE() specifically.

Is the idea that the variable processor can swap a generic set of functions to literals, and the Variables class contains the actual mapping we want to use?

[cecilycarver]

See what you think of this approach. I extracted the function mapping and removed the SessionContext interface, so there isn't any session-specific logic in VariableProcessor.

[barakalon]

I like this direction

[barakalon]

I don't think this class does anything?
I.e. should MySQLDatetimeFunctions just implement Mapping[str, Callable[[], Any]]?

And extending that even further - Do we MySQLDatetimeFunctions? Maybe we just need a type alias and some constants:

Functions = Mapping[str, Callable[[], Any]]

MYSQL_DATETIME_FUNCTIONS = {
    "NOW": lambda: timestamp.strftime("%Y-%m-%d %H:%M:%S"),
    "CURDATE": lambda: timestamp.strftime("%Y-%m-%d"),
    "CURTIME": lambda: timestamp.strftime("%H:%M:%S"),
}
MYSQL_DATETIME_FUNCTIONS.update(
    {
        "CURRENT_TIMESTAMP": functions["NOW"],
        "LOCALTIME": functions["NOW"],
        "LOCALTIMESTAMP": functions["NOW"],
        "CURRENT_DATE": functions["CURDATE"],
        "CURRENT_TIME": functions["CURTIME"],
    }
)

Then, later in Session:

functions = {
    **MYSQL_DATETIME_FUNCTIONS,
    # ... session related functions
}

[cecilycarver]

They can't be constants, since they depend on the timestamp, but I put them in static functions.

[barakalon]

Ah, I've been missing that timestamp dependency this whole time 🤦

[barakalon]

I had missed the timestamp dependency. Lets do it like you had before, just instantiate it when we need it.