pbxt-discuss team mailing list archive

[Martin Scholl <ms@xxxxxxxxxxxxx>]

As this is my first posting, I'd like to say "hello" to you all.

On Thu, Feb 11, 2010 at 4:19 PM, Paul McCullagh <
paul.mccullagh@xxxxxxxxxxxxx> wrote:
[snip]

> I guess the next step would be to defined an interface, and begin the
> implementation.
>
Beneath the missing bloody THD- and codeset / charset-related stuff... :-)
Even more, you will notice a lot of assert(0)s in the current version...
To be clear: the current state of the code is solely to "make it compile"
instead of "be maintable" or even "be clean". Please keep this in mind when
reading my "code".


> This raises the question of whether to use the MySQL handler interface, or
> to go in and replace ha_pbxt.cc altogether.
>
I'd propose to skip ha_pbxt.cc altogether and stick with a dedicated (and
pbly simplified) embedded API. ha_pbxt.cc is not part of the current
build-set anyways. :-)

One of the things I like the most about libraries like Tokyo Cabinet is its
straight-forward API. I would love to see embedded PBXT be easy like this as
well.

Embedded InnoDB's API might be a good start and reference for an API sketch:
http://www.innodb.com/doc/embedded_innodb-1.0/

IMHO what is open and where I would really appreciate your feedback /
comments:
- what language should the API be in? C or C++?
- In which format shall we store the table/db definitions? protobuff maybe?
Afair Drizzle does so, so we could borrow some code there...
- 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
- library naming: are you fine with libembpbxt?


> If you use the handler interface, then you will have to continue to
> simulate MySQL, which may not suite the API (you will have to call the
> handler functions in the same order that MySQL does).
>
> If you replace ha_pbxt, then you will have to nevertheless include some of
> the functionality in this code. For example, you should take over the init
> and shutdown code.
>

> What you need to keep is the "cursor" type paradigm.
>
> What I mean is, to do and index or table scan you do the following:
>
> - open a cursor for a table
>  * which means grap an XTOpenTable from the table pool
> - call init
>  * Initialize the scan.
> - Call search and next in a loop.
> - call exit
>  * Free resources
> - close the cursor
>  * which means return the open table to the pool
>
> All such actions need to be enclosed in a:
>
> - begin transaction
> ...
> - commit/rollback transaction
>
> The transaction is per thread, and all relevant information is stored in
> the XTThread structure.
>
Ok, a lot of open questions are answered by this. Thank you, Paul!


[snip]

Martin

P.S.: I will set up a TODO file to make it easier to track embedded PBXT's
progress