Hi Sergei, hi Padreig,
Very interesting work.
Am 13.10.2010 23:25, schrieb Padraig O'Sullivan:
> Hi Sergei!
>
> Thanks for the quick reply.
>
> On Wed, Oct 13, 2010 at 4:52 PM, Sergei Golubchik<serg@stripped> wrote:
>> Hi, Padraig!
>>
>> On Oct 13, Padraig O'Sullivan wrote:
>>> Hi!
>>>
>>> I have a patch with a new plugin point for query rewriting that I'd
>>> like to have considered. It allows someone to develop a plugin which
>>> can modify the text of a query before it is parsed.
>> What are the use cases?
>> Do you have any practical examples?
>>
>> Just to make it clear - I'm not referring to the query rewriting in
>> general, but precisely to your rewriting API, as you've implemented it.
>> What are the use cases for it? Can you show any practical rewriting
>> plugins that are built on this your API?
> A very simple explanation of my use-case is to transform a query with
> joins into a query on virtual tables that contains no joins. I need
> this transformation to be transparent to the user who can submit their
> original queries as before. I picked this point for the plugin as its
> much easier for me to parse the query myself than to work with the
> parse tree produced by MySQL.
>
> One other possible use-case which I had thought of is to implement a
> scheme for preventing SQL injection as a query rewriting plugin. This
> occured to me when reading this paper -
> http://www.springerlink.com/content/j2efhxbrf83xmd5g/ The proxy
> described in the paper could be implemented as a rewriting plugin. Not
> sure if its a real use-case but its just me thinking out loud.
Another use case would be date versioning aka audit trail of your data.
You could rewrite the query to access hidden tables from the user. We
currently implement this between the storage engine and the MySQL core.
Rewriting the query might be quite a bit slower than working directly on
the storage engine api but would make several other issues easier.
Altough for something like that it might be better to work on the parsed
query rather than the raw query text.
Also other security measures could be covered with this. E.g. to prevent
intrusion only allow specific queries (something like a MySQL proxy
currently handles). Or just a crazy Idea would be to load balance you
discs by creating tables on different harddrives and when you fill them
equally you can load balance them. So something like a horizontal
partitioning that is already available but maybe with the focus on
distributing workload on the tables rather distributing the data on
different tables. Another thought would be a "simulated" column store.
So you can transparently rewrite the queries for a columnar based layout
rather than a row based layout with the use of you favorite SE.
So many different use cases :)
Cheers,
Peter
--
Peter Benjamin Volk
Project Lead
DDEngine.org
An open source project
Phone: [+49] (0) 175 141 8841
mailto:peter@stripped
Bunsenstraße 3 | D-01139 Dresden | GERMANY
***********************************************************
