Also, one other thing we need to discuss is the following, which you
alluded to in an earlier email:
Suppose PBXT can handle ADD INDEX in an optimized fashion, but PBXT
does not implement the remainder of the ALTER TABLE statement and
prefers Drizzle's kernel to handle the other operations. In this
particular case, we need a way of allowing the engine to communicate
that it would like to handle *some part* of a statement internally,
and let the kernel handle other parts. This is an interesting
problem, and I can see at least three possible solutions. Let me know
what you think of either of these:
1) Establish two more flags for the StatementExecutionIntent:
INTENT_INTERNAL_AFTER_KERNEL
INTENT_KERNEL_AFTER_INTERNAL
In the first flag, the engine is telling the kernel that it wishes to
execute some part of the Statement *after* the kernel has finished
executing the statement. In the second flag, the engine is telling
the kernel it wants first crack at the statement.
I can see this solution being of medium-difficulty to implement, as
lots of edge cases would have to be tested...
2) Don't add new flags to StatementExecutionIntent, but instead have
the engine "do its thing" (e.g. optimizally implement the ADD INDEX
part of an ALTER TABLE) in the call to StorageEngine::endStatement().
3) Create a new plugin type: plugin::PostKernelStatementExecute:
namespace drizzled {
namespace plugin {
/**
* Modules implement a subclass of this class and register
* an instance of the class as a "listener" for when the
* kernel has completed execution of a Statement.
*
* For example, a storage engine might implement a subclass
* called OptimizedAddIndex which would listen for the kernel's
* completed execution of an ALTER TABLE statement and execute
* an optimal ADD INDEX clause for the ALTER TABLE statement.
*/
class PostKernelStatementExecute
{
public:
bool operator()
(Session &session, const message::Statement &statement);
};
}
}
Have the engine register a PostKernelStatementExecute trigger/hook.
This PostKernelStatementExecute would be a subclass of the above
plugin interface class and would allow the engine to react to certain
types of statements that it asks the kernel to execute "normally" but
wants to add some optimized path for...
Thoughts?
I like (2) above, because it is simple. I see 2 variations:
A) As per (2) above, let the engine do the extra stuff in
startStatement() and/or endStatement().
B) Add the following call sequence:
startStatement();
preStatement();
.... standard execution of the statement
postStatement();
endStatement();
Unless there is a reason why (A) or (B) will not work, then I think it
is better than adding additional flags or method registration to the API.
Everyone knows how to override a method, so the documentation for
preStatement(), for example, is simple:
This method is called after startStatement() and before the standard
execution of the statement. Override it if you need to do something at
this point.
Actually, so what you describe in B) above is really my original option
#3 :) The preStatement() and postStatement() calls would simply be
executing any registered PreKernelStatementExecute and
PostKernelStatementExecute triggers. My method is just a little more
"C++-like" and would allow us to use our existing drizzled::Plugin
infrastructure :)
I'll post a more in-depth example code in my summary shortly..
Cheers,
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
