Diego Medina wrote:
On Tue, Sep 29, 2009 at 10:21 AM, Jay Pipes <[email protected]> wrote:
I actually think that the better (as far as encapsulation goes) is to call
logging_pre_do() after Session::readAndStoreQuery().
Then again, I think
logging_post_do() should be moved into a Session-level context instead of
being in the parser where it currently is...
Did you mean logging_pre_do() should be moved into a session context ?
(or maybe both?)
In order to be able to rewrite the query text, I think I'd have to
either move logging_pre_do() inside Session::readAndStoreQuery(),
right before the return true line, or call logging_pre_do() inside
sql_parser.cc
inside case COM_QUERY: (but then it is not at the sesson-level :( )
Ah, I see. I wasn't aware that the logging_pre_do() hook was intended
as a transformation hook -- in other words, I thought it was a filtering
hook, and could not affect the original query itself.
This changes things for me. I'm frankly not sure about this one...
Clearly, there needs to be better documentation and API enforcement of
what private data of a Session that plugins have access to and, more
importantly, can change. I understand, clearly, that a StorageEngine
plugin needs to be able to change the underlying data, but should a
Logging plugin be able to do so? Or should it be held to a const
parameter (or be supplied a copy of the original query string)
These are all questions which really need to be documented and answered...
Cheers!
jay
Any takes?
-Diego
-jay
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
