drizzle-discuss team mailing list archive
Mailing list archive
Re: BLOB streaming is looking for a home in drizzle
Yep, I'm absolutely sure. :) It's a ridiculously unclear API. There
is a static class method named dropTable(), a static wrapper method
named dropTable() that takes a reference to a storage engine as a
parameter, and a pure virtual method named doDropTable(). The
difference between the two static dropTable() calls is only in its
parameters, and you have to read the code to figure out which is a
wrapper around all the engines and which isn't. Below, the first is a
wrapper around all engines, and the second dropTable() is a wrapper
around the single engine's doDropTable() pure virtual method:
returns ENOENT if the file doesn't exists.
int StorageEngine::dropTable(Session& session,
int error= 0;
error_proto= StorageEngine::getTableDefinition(session, identifier,
if (error_proto == ER_CORRUPT_TABLE_DEFINITION)
error_message.append(" : ");
my_error(ER_CORRUPT_TABLE_DEFINITION, MYF(0), error_message.c_str());
engine= StorageEngine::findByName(session, src_proto.engine().name());
if (not engine)
error= StorageEngine::dropTable(session, *engine, identifier);
if (error_proto && error == 0)
int StorageEngine::dropTable(Session& session,
error= engine.doDropTable(session, identifier);
Like I said, it's ridiculously unclear. It's pure virtual madness IMHO.
On Tue, Apr 20, 2010 at 12:40 PM, Barry Leslie
> On 4/20/10 8:34 AM, "Jay Pipes" <jaypipes@xxxxxxxxx> wrote:
>> On Tue, Apr 20, 2010 at 11:16 AM, Barry Leslie
>> <Barry.Leslie@xxxxxxxxxxxxx> wrote:
>>> On 4/20/10 6:24 AM, "Jay Pipes" <jaypipes@xxxxxxxxx> wrote:
>>>> On Mon, Apr 19, 2010 at 9:11 PM, Brian Aker <brian@xxxxxxxxxxx> wrote:
>>>>> On Apr 19, 2010, at 5:55 PM, Barry Leslie wrote:
>>>>>> 1) The first plugin point is one that just notifies me when a table was
>>>>>> dropped or renamed, or when a records is deleted. These notification
>>>>> You would want to do this in plugin::StorageEngine on dropTable().
>>>>> Currently anything that is an engine can "hear it". Adding a plugin point
>>>>> into that is fine.
>>>> The problem is then he has to create a storage engine plugin for
>>>> something that isn't a storage engine. Everything isn't a hammer.
>>>> What Barry needs is a simple plugin point that sends out a
>>>> representation of the parsed query tree before the engine gets it.
>>> Actually the Blob streaming daemon also support the storage engine API
>>> because it provides some of it's own system tables, some of which are very
>>> large and some of which support insert and update.
>>> But I think what Brian meant was to add it into StorageEngine::dropTable()
>>> and StorageEngine::renameTable() since storage engines are only notified
>>> when their own tables are dropped or renamed and the PBMS daemon needs to
>>> know about any table being dropped or renamed.
>> plugin::StorageEngine::dropTable() wraps all storage engines (yeah, I
>> know, it's not clear). plugin::StorageEngine::dropTable() calls
>> plugin::StorageEngine::doDropTable() on all storage engines...
>> plugin::StorageEngine::dropTable() is a static class method.
>> plugin::StorageEngine::doDropTable() is a virtual method each engine
>> implements. It's an unclear API, IMHO. It should have been
> Are you sure about this? I am looking at the code in the debugger and
> plugin::StorageEngine::dropTable() looks up the storage engine for the table
> being dropped which then uses it to call the engine's doDropTable().
> My breakpoint in the PBXT's doDropTable() never gets hit if I drop an INNODB
> Or have I missed the point here?
>>>>>> 2) The second plugin point is one some where after the 'Insert' or
>>>>>> statement has been processed but before the storage engine gets called.
>>>>> So you need a before trigger on insert? Why not use what the replication
>>>>> system has at that point?
>>>> See above, and Barry's email. Because it is fired after the storage
>>>> engine is notified, and, as Barry mentioned, he needs it before
>>>> Barry, I think it is certainly possible to create such plugin points.
>>>> The issue is going to be in the prioritization of that work. I can
>>>> probably get to designing the plugin points (base plugin classes to
>>>> put into /drizzled/plugin/ and the kernel callbacks to such plugins)
>>>> in about a month or so. In the meantime, you can give it a try and we
>>>> can work through things together? Sorry I can't be much more
>>>> help...trying to get a ton completed on the replication side of
>>>> One final alternative might be to ask Primebase to sponsor a Google
>>>> Summer of Code student who may not be accepted into the program this
>>>> year? We had 48 applicants and have only 8 slots, so there will be a
>>>> number who do not get accepted. Many of these students had excellent
>>>> proposals and may be willing to take on the above work? Just an
>>>> idea...trying to think outside the proverbial box. :)
>>> I am happy to do this myself so long as everyone is agreed on what it is I
>>> should be doing. Simplest for me would be to implement a "data-filter"
>>> plugin API that just does what I need. Ideally it would be better to try and
>>> design it so that it was more general and could be used for other purposes
>>> such as the ability to create trigger like plugins using the 'pre' and
>>> 'post' calls in the "data-filter" plugin.
>>> I would propose to model it after the logging plugin and put hooks into it
>>> before and after the calls to the engine level ha_write_row(),
>>> ha_update_row(), and ha_delete_row() calls in the cursor class as well as
>>> pre and post hooks into the StorageEngine dropTable() and renameTable()
>> This sounds fine to me. My request would be to make the API send
>> protobuffer messages that describe the parsed tree, and not pass the
>> LEX pointer around. That is welcoming a world of hurt, IMHO.
> Barry Leslie
> SNAP Innovation Softwareentwicklung GmbH
> Senior Software Engineer
> Tel: (001) 250 884 1820
> Fax: (001) 250 595 4460
> Email: Barry.Leslie@xxxxxxxxxxxxx
> Web: www.PrimeBase.com
> SNAP Innovation Softwareentwicklung GmbH, D-22765 Hamburg,
> Max-Brauer-Allee 50, Germany
> Amtsgericht Hamburg HRB 61066, Geschäftsführer: Ulrich Zimmer, Paul