:) I understand. I can't guarantee that phrases for errors that don't
exist in Drizzle will be kept, though! There will be plenty of other
stuff to translate though :)
-j
Francesco Riosa wrote:
+1 -1 +1 -1 +1
ok, it should be done, but is it true that all (or a good portion) the work
the translator did on launchpad will not be destroyed ?
please
On Friday 16 January 2009 20:29:53 Jay Pipes wrote:
Hi all!
Greetings from Columbus, Ohio, where the temperature this morning was a
balmy -15 degrees Fahrenheit (-26 degrees Celsius for you folks in weird
foreign lands) without wind chill.
Some background for the question(s) of the day:
(source files: drizzled/error.h and drizzled/error.cc)
1) We currently have a crap-ton (technical term) of error messages in
the server. In and of itself, this isn't a bad thing. The problem is,
we have 1650+ error codes and messages, many of which don't apply to
Drizzle's functionality.
For instance, a sampling:
ER_BAD_FT_COLUMN (bad fulltext column)
ER_REVOKE_GRANTS (not sure what "error" this is, but it doesn't apply to
Drizzle)
ER_UNKNOWN_TIMEZONE (we don't have em in the server..)
ER_SP_XXX (a bunch of errors for stored procs we don't have...)
ER_VIEW_XXX (bunch of errors for views we don't have)
ER_TRG_XXX (bunch of errors for triggers we don't have)
My rough guess is that more than 50% of the Drizzle error codes refer to
features we do not have.
2) There are, frankly, some downright weird errors. A sampling:
ER_GET_ERRMSG -- wonderfully recursive, I think.
ER_GET_TEMPORARY_ERRMSG -- no idea. :)
ER_CANT_AGGREGATE_2COLLATIONS soon followed by
ER_CANT_AGGREGATE_3COLLATIONS immediately followed by
ER_CANT_AGGREGATE_NCOLLATIONS -- not sure why 2 and 3 got special ones..
ER_READY -- ok...
3) Warning codes are completely mixed in with error codes. A sampling:
ER_WARN_DATA_TRUNCATED
ER_WARN_DATA_OUT_OF_RANGE
ER_WARN_INVALID_TIMESTAMP
ER_WARN_ALLOWED_PACKET_OVERFLOWED
4) Some eerily similar error codes:
ER_TRUNCATED_WRONG_VALUE
ER_TRUNCATED_WRONG_VALUE_FOR_FIELD
5) The enum which lists error codes is drizzled_error_code. The first
error number is 1000:
enum drizzled_error_code {
ER_ERROR_FIRST= 1000,
ER_HASHCHK= ER_ERROR_FIRST,
however, in the middle of the enum is this on line 468:
ER_STACK_OVERRUN_NEED_MORE=1436, // TODO: Test case looks for this int
So, the error codes change error numbers at that point because someone
didn't want to change a test case apparently...
OK, so with that background, here are the questions of the day:
Can we clean this up? Can we get rid of all the obselete error
messages? This will break compatibility with MySQL unless we assign
constant integers to each error code in the enum to match MySQL. This
may not be a bad idea anyway...
Can we remove all ER_WARN_XXX stuff from the error mixture? Warnings !=
errors IMHO.
Can we make the process of "registering" a new error code and message
more dynamic? With Drizzle's architecture leaning towards plugins, the
plugin should have the ability to register errors with the server
without having to restart the server...
Can we make the error messages themselves more flexible? For instance,
due to the static structure of the drizzle_error_code enum and
associated drizzled_error_message const char* array, there seem to be a
lot of repetitive error codes just so different error messages can be
given on essentially the same error event (e.g.
ER_CANT_AGGREGATE_2/3/NCOLLATIONS). Can we develop a more robust system
that allows an error code to be mapped to multiple error messages
distinguished by the number of parameters? This would be extremely
useful. For example, take an error code ER_INVALID_TIMESTAMP that I
wish to raise when either of the following statements occur:
SELECT FROM_UNIXTIME(-1);
CREATE TABLE t1 (ts_col TIMESTAMP);
INSERT INTO t1 VALUES (-1);
However, I want the error message to be as useful as possible. In the
first case, I wish the error message to read:
"Function 'FROM_UNIXTIME' received an invalid timestamp argument '-1'"
and in the second case:
"Attempted to insert invalid timestamp argument '-1' into column 'ts_col'"
Can we make the error system flexible enough so that an error code can
be mapped to multiple error messages and called appropriately depending
on the calls made to the server?
Anyone interested in showing this little area of the server a little TLC
and giving it the attention it deserves?
Discuss amongst yourselves!
-jay
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
