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_; } _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
