← Back to team overview

drizzle-discuss team mailing list archive

Re: BLOB streaming is looking for a home in drizzle

 

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().

>
>>>> 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



Follow ups

References