← Back to team overview

drizzle-discuss team 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,
                             TableIdentifier &identifier)
{
  int error= 0;
  int error_proto;
  message::Table src_proto;
  StorageEngine *engine;

  error_proto= StorageEngine::getTableDefinition(session, identifier,
src_proto);

  if (error_proto == ER_CORRUPT_TABLE_DEFINITION)
  {
    string error_message;

    error_message.append(identifier.getSQLPath());
    error_message.append(" : ");
    error_message.append(src_proto.InitializationErrorString());

    my_error(ER_CORRUPT_TABLE_DEFINITION, MYF(0), error_message.c_str());

    return ER_CORRUPT_TABLE_DEFINITION;
  }
  engine= StorageEngine::findByName(session, src_proto.engine().name());

  if (not engine)
  {
    my_error(ER_CORRUPT_TABLE_DEFINITION, MYF(0),
identifier.getSQLPath().c_str());

    return ER_CORRUPT_TABLE_DEFINITION;
  }

  error= StorageEngine::dropTable(session, *engine, identifier);

  if (error_proto && error == 0)
    return 0;

  return error;
}

int StorageEngine::dropTable(Session& session,
                             StorageEngine &engine,
                             TableIdentifier &identifier)
{
  int error;

  engine.setTransactionReadWrite(session);
  error= engine.doDropTable(session, identifier);

  return error;
}

Like I said, it's ridiculously unclear.  It's pure virtual madness IMHO.

-jay

On Tue, Apr 20, 2010 at 12:40 PM, Barry Leslie
<Barry.Leslie@xxxxxxxxxxxxx> wrote:
>
>
>
> 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:
>>>>> Hi!
>>>>>
>>>>> 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
>>>>>> events
>>>>>
>>>>> 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
>> plugin::StorageEngines::dropTable().
>>
>
> 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
> table.
>
> Or have I missed the point here?
>
>>>
>>>>>> 2) The second  plugin point is one some where after the 'Insert' or
>>>>>> 'Update'
>>>>>> statement has been processed but before the storage engine gets called.
>>>>>> The
>>>>>
>>>>> 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
>>>> that...
>>>>
>>>> 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
>>>> things..
>>>>
>>>> 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. :)
>>>>
>>>> Cheers,
>>>>
>>>> -jay
>>>
>>> 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.
>>
>> -jay
>
> -------------------------------------------------------------------------
> 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
> McCullagh
> -------------------------------------------------------------------------
>
>
>
>



References