← Back to team overview

drizzle-discuss team mailing list archive

Re: Improvements to Storage Engine API


Stewart Smith wrote:
On Mon, Jan 04, 2010 at 03:08:18PM -0500, Jay Pipes wrote:
In the long run, I don't think we should be passing anything that is
not a GPB in the storage engine API except possibly a reference to
the current Session object.  GPB messages can be constructed from
anything that is now a struct or class (LEX, JOIN, etc...)  The
advantage to a GPB message is clearly in documentation, versioning
and serialization of course.

Very much disagree.

GPB is designed for IPC with explicit warnings about how you should
not rely on these data structures within your software as data
structures if you're not gonig to be pumping them over the wire (or
otherwise serialising them). There's also explicit advice to copy the
data out of the message into your own data structure if you have
performance critical code.

I'm not talking about using GPB messages for performance critical code, Stewart. I'm talking about using GPB messages in the storage engine API because the API represents a *description of the action the storage engine is to take*. GPB messages, by definition, *describe something* (in a serializable, documented, version-future-compatible, and standardized way).

Using GPB everywhere for DDL isn't an issue - DDL is never that
performance critical. But for actual DML... it gets incredibly so. The
foo() method on a GPB class is infinitile more complex than a getFoo()
{ return foo; } method.

Really? Infinitely more complex? Here is, as a boring and normal example, the TransactionContext::transaction_id() method:

inline ::google::protobuf::uint64 TransactionContext::transaction_id() const {
  return transaction_id_;

Follow ups