pbxt-discuss team mailing list archive

[Stewart Smith <stewart@xxxxxxxxxxxxxxxx>]

On Thu, Feb 11, 2010 at 11:45:25PM +0100, Paul McCullagh wrote:
> protobuf may be an overkill for the initial implementation.

The Drizzle table protobuf message is pretty simple. It's also really
easy to deal with programatically and there exists libraries for
turning it back into SQL.

> How are you planning to do create table? The innodb API does it by
> building a create table structure with various API calls.
> 
> By submitting a CREATE TABLE statement as text, you can save a lot
> of API routines.

But it also means you have to have a compatible CREATE TABLE syntax.
Especially problematic for non-SQL frontends... or SQL frontends that
use a different dialect.

> PBXT already has a parser for CREATE (and ALTER) table statements.
> So, you could accept the text and feed the parser.

What about switching to the drizzle table proto. It means that there
will be little code for drizzle, easy api for embedded pbxt and a bit
of a wrapper around for MySQL (but a lot better than parsing sql)

> Then, you could actually store the table definition as a CREATE
> TABLE statement. When the table is loaded you just invoke the
> parser. The CREATE TABLE text could be stored in a separate file,
> like the .frm file, for each table.

we toyed with that idea... but the table proto gives us a lot more
flexibility - other software can interact with it (e.g. in replication
stream) as well as our own software. You need a data structure to
represent part of it anyway... and the table proto gives us that. 

> Alternatively the text could be stored in the header of the .xtd
> file, where I already store the foreign key information (the foreign
> key information is actually stored as SQL text).

we'll soon have fkey information in the table proto too.

> It is also pretty much the division of work between MySQL code and
> PBXT today. However, the division is not so clear in the code.

Embedded PBXT would make it a lot easier to maintain both the Drizzle
and MySQL storage engines. just have ha_pbxt.cc be different for each
one.

This is the way we're looking at it for innodb. using the embedded
innodb library (and just linking to it) instead of porting the whole
innobase codebase.

> >- else, should table serialization / deserialization be pluggable
> >or even be purely programmatic? I am fine with this, too, as it is
> >an _embedded_ library and I'd guess most people will control pbx
> >programmatically anyways
> 
> Although I spoke mainly about the textual interface above, I am
> really flexible on this. I think both solutions have there
> advantages.
> 
> Use whichever is best and easiest for you at the moment, which may
> be simply writing your own stuff! :)

Proto is very, very easy :)


-- 
Stewart Smith