On Fri, 23 Apr 2010 11:09:11 -0400, Jay Pipes <[email protected]> wrote: > Hi all! > The existing API call is like so: > > virtual int Cursor::doInsertRecord(unsigned char *new_row); > > The call returns an integer that corresponds to an engine error code > (with 0 being "success"). The problem with this API, as briefly > outlined by Kostja in this MySQL internals mailing list post:
I think there's a more fundamental problem; an errno is not particularly descriptive. For a start, we want to know if we succeeded in inserting (err... or replacing) a row. But if we fail, we want something rather descriptive. In the case of failing due to a duplicate key, the current API is that you *must* store away which key caused the violation for later retrieval from a ::info(HA_STATUS_ERRKEY) call at which point you store it in errkey and return 0; Makes *total* sense. If you don't store away the error key (or can't get at it), then ON DUPLICATE KEY UPDATE doesn't work. You then need to set errkey to -1 (not MAX_KEY, like in other error conditions... as that'll cause an access beyond array bounds in the key structures of the table) so you can error out gracefully when not supporting ON DUPLICATE KEY UPDATE. *Then* there's the issue of every single possible type of error you can get from an engine. Hopefully they fit into the various Drizzle/MySQL error codes. If not, you can be all generic and vague! When I start to think what could constitute an error I come up with: - bool success/fail simple: did we do something, anything at all successfully or did we fail. - errno (as simple as ENOENT or ENOMEM or something) - drizzle_errno (HA_ERR_DUPP_KEY or something) - plugin_errno (e.g. innobase could come back with DB_MISSING_HISTORY) and some structured information dependent on the error number. the idea behind the plugin errno is that you have a more structured error that could be parsed by various monitoring/logging systems to help aggregate and track down the causes of specifics (e.g. engines may have different error codes for various types of corruption) something should also be there for pointer to gettexted string something should also be there for snprintf parameters for the gettexted string (or key value pairs? something anyway... and it must always be able to work with gettext) this could be used to construct human-readable engine specific errors. e.g. "index %u page %u corrupt. invalid magic number. expected %u, got %u" or "transaction aborted due to node %u failure." thoughts? (these aren't too well thought out yet) -- Stewart Smith _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
