[asterisk-bugs] [Asterisk 0013097]: [patch] several fixes in res_config_sqlite

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13097 
====================================================================== 
Reported By:                gknispel_proformatique
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   13097
Category:                   Resources/res_config_sqlite
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     feedback
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 131605 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             07-17-2008 08:06 CDT
Last Modified:              07-18-2008 10:16 CDT
====================================================================== 
Summary:                    [patch] several fixes in res_config_sqlite
Description: 
The attached patch fixes three things:

1) Some const qualifiers are added on static constant strings.
2) The schema of the CDR table is changed to something more similar to
other CDR backends. (start is replaced by calldate, which is at the
beginning)
3) ast_cdr_disp2str(cdr->disposition) is stored in the disposition column
(as in other CDR backends) instead of the numeric code cdr->disposition
====================================================================== 

---------------------------------------------------------------------- 
 gknispel_proformatique - 07-18-08 10:16  
---------------------------------------------------------------------- 
Some reasons were given in commentaries.

The "training" reason is not a valid reason anymore to keep the code
here.

The second one, to have the same database open at only one place for all
kinds of operations, could be, but I don't know what really happen in the
real life. The rational behind the claim of reliability and performance
improvement is that SQLite does not support simultaneous write operations
(the whole base is locked) so under high pressure there is a theoritical
risk that 
RES_CONFIG_SQLITE_BEGIN / RES_CONFIG_SQLITE_END loop is used more that
once, and under very high pressure that it loops until
RES_CONFIG_SQLITE_MAX_LOOPS then fails. This is completely impossible if
the only access to the same base are serialized with the same mutex. One
possible solution could be that res_config_sqlite exports its mutex that is
then used by cdr_sqlite, but this introduce a dependency that is IMHO not
better that having all the code in res_config_sqlite. Another solution
could be to introduce a new sqlite "middleware" module that would be used
by both cdr_sqlite and res_config_sqlite  but this complicate things and
maybe this is even technically impossible now because i don't think there
is a way to describe and enforce dependencies between modules. The volume
of code in res_config_sqlite is probably too small to complicate things so
much. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
07-18-08 10:16  gknispel_proformatiqueNote Added: 0090453                       
  
======================================================================