[asterisk-bugs] [Asterisk 0015170]: [patch] MySQL ENUM Type Not Detected

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=15170 
====================================================================== 
Reported By:                leobrown
Assigned To:                lmadsen
====================================================================== 
Project:                    Asterisk
Issue ID:                   15170
Category:                   Addons/cdr_addon_mysql
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     assigned
Asterisk Version:           SVN 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-05-21 07:45 CDT
Last Modified:              2009-08-20 16:09 CDT
====================================================================== 
Summary:                    [patch] MySQL ENUM Type Not Detected
Description: 
The raw values for the AMAFLAGS column are detected by a switch case that
checks all numeric types. Unfortunately ENUM is not in the list. ENUM is
technically a numeric type. So if you have the column definition:

  amaflags ENUM('DOCUMENTATION','BILLING','OMIT')

This will work. However, if you have the definition:

  amaflags ENUM('info','outbound','inbound')

This will *not* work and the column will be set to NULL due to an
unparsable value. By adding the ENUM column type instead, both syntaxes
will work!

====================================================================== 

---------------------------------------------------------------------- 
 (0109410) leobrown (reporter) - 2009-08-20 16:09
 https://issues.asterisk.org/view.php?id=15170#c109410 
---------------------------------------------------------------------- 
Hi, interesting point.

I do disagree (hence the ticket!) that ENUM is only 'technically' an ENUM
type. It's very common for people to implement ENUM and SET numerically.
It's right up at the start of the relevant man page

  http://dev.mysql.com/doc/refman/5.0/en/enum.html
  "Each enumeration value has an index. Values from the list of allowable
elements in the column specification are numbered beginning with 1."

And from an implementation viewpoint, it makes a lot of sense. CDRs can be
stored on remote systems but the limitation of the ENUM field as text means
that the remote server HAS to call the values INFO, OMIT, and BILLING,
which really only relate to very specific scenarios. In many
implementations people use these as a kind of VERBOSE, INBOUND, OUTBOUND
setup.

Finally, from your point that "if the enum specifies the possible values
out of order" there will be an issue, I really don't think this should be
considered an issue. The CREATE TABLE syntax is given with the module and
this is what is used. Why, if your point is valid, is there a test in the
module for numeric types in the AMAFLAGS field?

However, you do have the last word - but I can say that from an
implementation PoV, this change makes a lot of sense, because the remote
system can use this column more dynamically.

Perhaps a global setting for MySQL CDR to provide this functionality would
be sufficient. If you feel that is also uncalled for for some reason, then
I happily rescind the patch... We can continue to use it internally only,
but I thought others would benefit. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-08-20 16:09 leobrown       Note Added: 0109410                          
======================================================================