pbxt-discuss team mailing list archive

[Paul McCullagh <paul.mccullagh@xxxxxxxxxxxxx>]

Hi Stewart,

On Feb 12, 2010, at 3:10 AM, Stewart Smith wrote:

> 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.

OK, this is a good point.

> > 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.

Makes sense. So in the long run (or maybe sooner) embedded PBXT would  
the way to go for Drizzle as well.

However, as I mentioned previously, the data types, including  
comparison functions are external to the PBXT kernel.

We would need a way for Drizzle to declare what types it uses, and  
supply the comparison functions. At least for all types that are not  
standard C types.

This method has the advantage the we are sure that the engine handles  
data types in the exact same was as the server.

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

Well, you've made a good case. Thanks for your input.

Martin: it is up to you. You are doing the work... :)


--
Paul McCullagh
PrimeBase Technologies
www.primebase.org
www.blobstreaming.org
pbxt.blogspot.com