← Back to team overview

drizzle-discuss team mailing list archive

Re: File Deletion issues for Storage Engines


Hi Brian,

On Dec 15, 2009, at 11:49 PM, Brian Aker wrote:

On Dec 13, 2009, at 4:08 AM, Toru Maesaka wrote:

I'm not entirely confident but in the current storage API, there is,
StrorageEngine::doGetTableNames() where you must provide/set the name
of tables to the provided reference to a std::set<string> object.

You are starting to see how the system will work for dropDatabase() :)

I wrote some of the code for this a while ago. MySQL would sometimes orphan files from shutdown that needed to be cleaned up. Its method is to just do an unlink on them. The problem is that Innodb, or really any engine that kept state, would then loose the tables in it system.

For Drizzle we look at each file, find the owner and call delete table (or for the orphaned files we will delete). The idea has been to morph this code to the following:

1) Do a CachedLookup for any registered .dfe file (aka... all engines register their extension if they have one). This way we don't do multiple nested loop over the directory.

2) We start the database drop.

2) We call dropTable() (notice... not doDropTable()... we want to go through the entire process).

3) We then call finish drop Scehma() for anyone who needs to do any final cleanup.

4) We call drop finishDropSchema().

So process looks like this:

dropSchema {

getTableNames() <-- sort by engine

doStartDropSchema() {}

while (...)

doFinishDropSchema() {}


I don't quite understand this code, for example, when is dropTable() called?

Maybe you could re-write it in terms of (theoretical) engine API calls.

I guess what interests me the most is where the API is heading, not the process by which the Drizzle code must be transformed to get there.

Although I understand that that is major concern for you!

The above allows for transactional DDL to occur during the drop for a particular engine (possibly all, but we won't go that far just yet). The interface call dropSchema() is one for the system, and not for a particular engine. The do..() are all private/(protected?)... aka no one outside of the path can call them. Engine can ignore the begin to a drop schema if they want, or they can whatever they need... like say batch the entire operation.

Where the getTableNames() is, we will eventually add a call after that to clean up any views. AKA... walk the dependency and apply. Trigger as discussed previously are owned by engines, so we don't need to do anything there.

Best regards,


Paul McCullagh
PrimeBase Technologies