Ah, now I see. Yes, that makes sense. Thanks Jay!
/Matz Jay Pipes wrote: > Mats Kindahl wrote: >> Brian Aker wrote: >>> Hi! >>> >>> On Aug 21, 2008, at 1:09 AM, Mats Kindahl wrote: >>> >>>> I'm not entirely sure about the connection between ha_discovery() and >>> Discovery is just the current tie in point. I do not expect it to stay >>> the same at all. >>> >>>> common .frm format or discovery mechanism, then there should be a >>>> library and/or a set of helper function for the engine to use. That way, >>>> an engine can opt to use the .frm files if they feel like it, while >>>> engines that want to do something special can roll it themselves. >>> Agreed. This is just a default discovery method in my book. >>> >>>> However, I think that the parsing should be handled by Drizzle and that >>>> a table definition description (a.k.a., "parse tree", but I really don't >>>> like that term) should be passed to the engine. >>> I want an engine to be able to handle/read that definition (and restore >>> it). For Innodb this is a requirement for its catalog (and for Archive >>> for portable tables). >> I'm not sure I follow what you're saying, but there's quite a lot of >> work to write a tokenizer and a parser for SQL, even for a small >> fragment. Allowing Drizzle to do the dirty work and pass some form of >> pre-digested description saves a lot of work for everyone. > > I think we're all pretty much on the same wavelength. What Brian is > suggesting is that the table proto buffer message class will be passed > from the parser to storage engine (upon a CREATE TABLE, ALTER TABLE, > CREATE INDEX, ALTER INDEX). The parser will do the following, AFAIU: > > Do the standard parsing of the SQL statement into a Lex class. The Lex > class will have a member variable, Lex->proto which will store a pointer > to, initially, a blank drizzle::Table proto buffer message class. > > A library function (fill_proto_table()?) will be responsible for > traversing the Lex's tree and "filling in" the Lex->proto's members > (basically, it will be doing what is currently mapped out in > /drizzled/serialize/table_writer.cc). > > mysql_execute_command() will of course pass this filled-in Lex->proto > instance to the storage engine identified in the CREATE TABLE () > ENGINE=XXX statement. The storage engine can then use the > google::protobuf::Descriptor class to examine the passed in table > definition and determine if the definition is valid or not. The storage > engine can then write the definition to disk and begin the creation of > the table. > > For ALTER statements, the same basic process would happen, but the > storage engine would read in the table's proto buffer message stored > file and compare that instance with the one supplied in Lex->proto(). > > Brian, I am on target here? Mats, does this make more sense? > > -jay > >>> Cheers, >>> -Brian >>> >>>> In general, I prefer narrow interfaces, and allowing the engines to be >>>> responsible for the format and discovery and "just" act at table >>>> factories is much easier for each involved entity while still >>>> maintaining maximum flexibility. >>>> >>>> Just my few cents, >>>> Mats Kindahl >>>> >>>>> Cheers, >>>>> -Brian >>>>> >>>>> -- >>>>> _______________________________________________________ >>>>> Brian "Krow" Aker, brian at tangent.org >>>>> Seattle, Washington >>>>> http://krow.net/ <-- Me >>>>> http://tangent.org/ <-- Software >>>>> _______________________________________________________ >>>>> You can't grep a dead tree. >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Mailing list: https://launchpad.net/~drizzle-discuss >>>>> Post to : [email protected] >>>>> Unsubscribe : https://launchpad.net/~drizzle-discuss >>>>> More help : https://help.launchpad.net/ListHelp >>>> -- >>>> Mats Kindahl >>>> Lead Software Developer >>>> Replication Team >>>> MySQL AB, www.mysql.com >>>> <mats.vcf> >>> -- >>> _______________________________________________________ >>> Brian "Krow" Aker, brian at tangent.org >>> Seattle, Washington >>> http://krow.net/ <-- Me >>> http://tangent.org/ <-- Software >>> _______________________________________________________ >>> You can't grep a dead tree. >>> >>> >>> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~drizzle-discuss >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~drizzle-discuss >> More help : https://help.launchpad.net/ListHelp > -- Mats Kindahl Lead Software Developer Replication Team MySQL AB, www.mysql.com
begin:vcard fn:Mats Kindahl n:Kindahl;Mats org:Sun Microsystems adr;quoted-printable:;;Tegv=C3=A4gen 3;Storvreta;SE;74334;Sweden email;internet:[EMAIL PROTECTED] title:Lead Replication Software Developer x-mozilla-html:FALSE version:2.1 end:vcard
_______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
