pbxt-discuss team mailing list archive

[Paul McCullagh <paul.mccullagh@xxxxxxxxxxxxx>]

Hi Martin,

On Feb 12, 2010, at 2:54 PM, MS wrote:

> [snip]
> > > 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.
> > >
> > >
> > > - 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! :)
> > > I guess hardcoding table definitions will be the most easy way for  
> > > now.
> >
> > OK, so the wrapper class would just know the format of the tables?
> I'd guess so. I am just reading the code related to ha_pbxt::open to
> understand how tables are actually opened.

In that case don't be confused by:

xt_ha_open_database_of_table()

PBXT has only one "database" (in the sense it is used in the code).

Let me explain:

In the PBXT sense, a database is a collection of tables (which are  
referenced by a path), and a transaction log. A database must be  
recovered before it can be opened.

Originally, PBXT was created to handle multiple databases. In this  
implementation, the MySQL database concept was mapped one-to-one to  
the PBXT database concept.

The problem was, renaming a file from one database to the next did not  
work in this setup. For example, the following did not work:

ALTER TABLE test.t1 RENAME TO test2.t1;

For some reason this was absolutely unacceptable.

The simplest solution was to change the implementation to work with  
one global database. The macro XT_USE_GLOBAL_DB determines this  
behavior, and is defined by default. In this case the global database  
reference is stored in 'pbxt_database'.

Anyway the main point is that you need to decide if the embedded  
version will support multiple or a single global database.

I would recommend a global database because the other code has not  
been used for a while.

The global database, and the recovery can be run when the library init  
is called.

For MySQL we start a thread to do recovery in the background! This is  
only necessary because MySQL holds the lock_PLUGIN when called the  
engine init function. This lock prevents us from opening .FRM files!

This would not be necessary for the embedded lib.

> My thinking is this: hook into the .frm-loading code the strategy  
> design
> pattern. By this different concrete table metadata de-/serializations
> are possible, with the hard-coded flavour being the first. Makes  
> sense?

Yes, once you get things running with the hard coded version if will  
be easier to see what has to be done to make metadata storage dynamic.

> 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... :-)
> There really is not much code involved doing this, except the
> automake/autoconf-part which I don't know much about.
>
> What do you think should be done?

I think we can just take it one step at a time.

You seem to have a format in mind for hard-coding the table meta data?

Are you thinking of name/value pairs?

Do you require multiple tables to start with?

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