← Back to team overview

drizzle-discuss team mailing list archive

Re: Improving the Engine API

 

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



Follow ups

References