I could possibly compromise on what Stewart/you talk about here.
Basically, you're discussing changing the AlterTableStatement message
from the proposed:
message AlterTableStatement
{
required Table before= 1;
required Table after= 2;
}
to:
message AlterTableStatement
{
message AlterColumn
{
required string before_name;
required string after_name;
// other stuff...
}
message AlterIndex
{
// fields describing index changes...
}
// .. many more submessages like DropColumn, etc
repeated AlterColumn alter_column= 1;
repeated AlterIndex alter_index= 2;
repeated DropColumn drop_column= 3;
repeated DropIndex drop_index= 4;
// etc, etc
}
Whereas I prefer to keep the message simple (i.e. the former message
format) I can see a case for the latter.
The above, however, does not affect my original proposal to use GPB
Statement messages in the engine API and to adapt the engine API to use
startStatement(), endStatement(), etc and to allow the engine to advise
the kernel it wishes to handle all, part, or none of the statement
execution.
Cheers,
Jay
Paul McCullagh wrote:
On Dec 15, 2009, at 11:08 PM, Stewart Smith wrote:
On Tue, Dec 15, 2009 at 09:16:42AM -0800, Brian Aker wrote:
On Dec 14, 2009, at 9:27 PM, Stewart Smith wrote:
You can go from actions to SQL easily.
You can also use the actions to simply write code that does the alter
on non-sql systems (e.g. an applier that just uses Embedded InnoDB)
SQL statements are interpreted by an engine. One engine may need to
do a rebuild of a full table, another may not.
If an engine can just "add" a column, then the action for it may just
be "add column". If another engine needs to copy/rename/delete then
it will have a different set of actions.
We need to be descriptive about the change, but the actual mechanics
are up to the individual engine.
I see it working as a 2 step process.
step 1 is pass a list of changes to the engine and it returns a list
of what it can't do. (this could then be used for EXPLAIN ALTER
TABLE).
If the list of what it can't do is not empty, we do a copying alter
table.
Yup, but actually I see only 2 possibilities here:
1. The engine can handle ALL actions internally.
2. We use the (default) copy alter table method.
I don't see why we would need a combination of 1 and 2.
For example if an ALTER TABLE calls for 2 actions: ADD COLUMN and ADD
INDEX, and the engine can only do ADD INDEX internally, then it would
make no sense to use method 1 for ADD INDEX and method 2 for ADD COLUMN.
In fact, if an ALTER TABLE adds 2 indexes it may be better to for the
engine to pick method 2 (which does all changes at once), if its
implementation of ADD INDEX can only add one index at a time.
This would be applied the same way on a slave, as we have the original
set of actions in the replication stream.
Yes, I know what you mean. You mean the same actions (ADD COLUMN, ADD
INDEX) are executed on the slave, but they may use a different method (1
instead of 2, or 2 instead of 1).
--
Stewart Smith
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
--
Paul McCullagh
PrimeBase Technologies
www.primebase.org
www.blobstreaming.org
pbxt.blogspot.com
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
