drizzle-discuss team mailing list archive
Mailing list archive
Re: Improving the Engine API (was Re: New PBXT Drizzle-specific storage engine...)
On Dec 3, 2009, at 6:13 PM, Brian Aker wrote:
On Dec 3, 2009, at 9:03 AM, Jay Pipes wrote:
Since this actually lends itself to my current docket of work, I
will work on implementing these suggestions this week and will post
back to this mail with a link to the code review of the relevant
merge for you to add your input.
A renaming of external_lock() also needs to happen as well. With
MyISAM soon to be gone this becomes a bit more straightforward to
Absolutely. As far as I know, even the name external_lock() is an old
one, with a different meaning to what it is being use in the API today.
Paul, store_lock() is just about gone at this point.
I use it to convert a lock of type (for example) TL_WRITE to
TL_WRITE_ALLOW_WRITE, just like InnoDB, to allow concurrent updates.
But otherwise, I don't specifically require the call, especially if
table locking is to be handled differently.
I am working out the changes to alter table at the moment (I did a
review with Stewart on the phone last night). I am not sure how much
you rely on it, but expect a push that will completely remove it
within the month.
I would be interested in how you are planning to change this stuff.
Basically I see the following, external_lock() is used to do a number
1. Acquire a handler for exclusive use by a thread (and then use it as
2. Lock a table (implicitly, or via an explicit LOCK TABLE call).
3. Signal the start of a transaction or statement.
If we add the functions discussed previously then (3) above need no
longer be done in external_lock().
What are you planning to do about (1) and (2)?
I am still finding odds and ends in Cursor that should be up in the
SE. Once I have it all gone and the new locks in place I am going to
do a review of cursor. From playing around with the BDB and Innodb
Embedded interface I have some ideas on what should perhaps be done.
I believe most of those changes will wait until next year though,...
and maybe we can talk about that in person at a conference.
On a completely related note, I am ponding a name change of "Storage
Engine" to "Data Management", since that is really more what we are
doing. Any thoughts on that?