On Wed, Apr 28, 2010 at 11:00 AM, Stewart Smith <[email protected]>wrote:
> 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. > IMHO, these are overly complex just for supporting few extra functionality. In my very very humble opinion, it is worth taking the pain to remove these cancerous parts too. (I know you drizzle hackers already done many) is there any place we can submit my memorandum? I hope most of the community will vote for a less complex and less buggy code. > > *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) > Good thoughts on error reporting. a common compliant from end users are (irrespective of what software they are fighting with) "This error completely misleading. i wasted my hours in troubleshooting" In a hurry to display a good looking message, developer maps the internal errors into something generic. that will be like language translation. all essence will be lost in the conversion. as an end user. it matters for us how easily we can pin point the problem. so i vote for engine specific errors from engines. even it is worth to report back just error number and have an dictionary outside the software. (just like oracle does) Thank you, Jobin.
_______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
