← Back to team overview

drizzle-discuss team mailing list archive

Re: BLOB streaming is looking for a home in drizzle


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

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

Follow ups