Open lizztheblizz opened 1 year ago
@lizztheblizz how do you see this being configured, starting with the context of a consumer of pscale connect
?
I feel like fully supporting syntax like ProxySQL with it's in-memory database is quite over the top, but being able to support some CLI arguments or runtime config would be more ideal in our situation.
One option I was considering, we could expose some HTTP/RPC interface to add/remove/enable/disable things at runtime. But I kinda feel like we can back this by a config file instead to just add in the rules.
I think having static config in this case can be quite a bit more flexible, or even being able to reload the config through a SIGHUP or similar would be better than some in-memory and SQL interface.
What are your thoughts?
Slack Context link: https://planetscale.slack.com/archives/C02JPHAQHB7/p1701190291867839
This request is heavily inspired by features available in ProxySQL, which we use as a stop gap at times in Tech Solutions and Customer Engineering to work around various compatibility challenges for customers with limited ability/capacity to implement changes.
Many customers and prospects coming to us with legacy environments experience some or all of the below challenges:
lowercase_table_names
, which break compatibility with Vitess (i.e. case insensitivity expectation on table names and table aliases)If we had a way to rewrite queries on the fly, based on individualized sets of rules per customer, we could overcome many of these challenges, and reduce the friction to initial adoption.
Core implementation goals might be:
As discussed on Slack, we currently use ProxySQL to help offer a lot of this, and having this functionality built into
pscale
would offer a solution analogous to that without needing to resort to 3rd party tooling. However, if this were built straight into Edge, it would offer us the exact same benefits without requiring the customer to do anything.