← Back to team overview

drizzle-discuss team mailing list archive

Re: BLOB streaming is looking for a home in drizzle


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.

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


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