pbxt-discuss team mailing list archive

[Martin Scholl <ms@xxxxxxxxxxxxx>]

Hello Stewart,


On Tue, Feb 16, 2010 at 7:43 AM, Stewart Smith <stewart@xxxxxxxxxxxxxxxx> wrote:
> On Fri, 12 Feb 2010 14:54:23 +0100, MS <ms@xxxxxxxxxxxxx> wrote:
>> Or even stick to drizzle's table.proto completely and leaving everything
>> elese out. The de-/serialization part is then just trivial. We could
>> even store the protobuf definitions in a special system row
>> file... :-)
>
> This is what I'm doing with the embedded-innodb engine (a storage engine
> for Drizzle that uses the embedded innodb library).
>
> Note that ever generating a FRM is roughly akin to making life from the
> raw chemicals... you may want to store it there too. If the proto was
> used internally, you could store it there alongside the FRM.
>
> This could be a on-disk upgrade path from mysql to drizzle...
>
> or, for embedded, from embedded to drizzle.
-- or vice versa :-)

>
> Taking a bunch of data on disk in an embedded engine and being able to
> query it using SQL can be useful.
I followed your hint and added support for table.proto to
lp:embedded-pbxt . I like the migration- and testing-argument,
although I'd guess the table-meta-datafiles will have to get rewritten
as Drizzle has different types and type-ids.
Nevertheless, it is a nice-to-have for the future.

Furthermore, there is still the open problem on how rows are to be
stored physically. Afaics, if we are to support opening embedded pbxt
databases via drizzle / mysql, we will either have to support having
different row-formats, or we will have to stick with mysql's or
drizzle's row-format.
Is there any objection against to stay with MySQL's or Drizzle's
format? (btw is there any difference?)


Martin