Brian Aker wrote:
On a completely related note, I am ponding a name change of "Storage Engine" to
"Data Management", since that is really more what we are doing. Any thoughts on that?
I like StorageEngine better. But then again, I would prefer that we not
have so many methods in StorageEngine either, and instead implement
private inheritance to add related functionality to the engine.
For instance, instead of having commitTransaction(),
prepareTransaction(), etc, on StorageEngine, I would prefer instead to
do something like this:
(I've left out obvious parameters for brevity's sake)
namespace drizzled
{
namespace plugin
{
class StorageEngine
{
public:
int createTable();
int alterTable();
int dropTable();
// etc, etc. for DDL operations
private:
virtual int doCreateTable();
virtual int doAlterTable()
virtual int doDropTable();
// etc, etc for private implementation of DDL operations
};
class TransactionProcessor
{
public:
int startTransaction();
int prepareTransaction();
int commitTransaction();
int recoverTransaction();
int rollbackTransaction();
// etc, etc for Transactional operations
private:
virtual int doStartTransaction();
virtual int doPrepareTransaction();
virtual int doCommitTransaction();
virtual int doRecoverTransaction();
virtual int doRollbackTransaction();
// etc, etc for private implement of transaction operations
};
} // end namespace plugin
} // end namespace drizzled
Then, engine *implementors* will create a storage engine which performs
transactional operations like so:
// note private inheritance of TransactionProcessor means
// "is implemented in terms of", and not "is a" !
class PBXTEngine :public drizzled::plugin::StorageEngine,
private drizzled::plugin::TransactionProcessor
{
// PBXT-specific data...
};
// Implement transaction-aware engine...
int PBXTEngine::doCreateTable()
{
// Start our own transaction...
if (transactionStarted())
commitTransaction();
startTransaction();
// do the creation of the table internally...
int error= pbxt_create_table();
if (error == 0)
commitTransaction();
else
rollbackTransaction();
return error;
}
TransactionProcessor::commitTransaction() would be a kernel-level method
that would not be virtual, and might look something like this:
int TransactionProcessor::commitTransaction()
{
// Notify listeners that a transaction was committed
notifyTransactionCommit();
// Ask PBXT (i.e. the implementing engine) to commit internally
return doCommitTransaction();
}
The nice thing about this kind of private inheritance (vs. the existing
solution of continuing to just appending endless numbers of methods to
both the Cursor and StorageEngine class interfaces) is that engines
which do not need transaction processing semantics or methods never have
to implement or even think about implementing methods concerning
transaction processing... which makes the interface cleaner and more
efficient (since engine structures only include methods which make sense
for what the engine actually implements...
Anyway, just food for thought...mostly just brainstorming.
-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
