|Summary:||ASTERISK-17106: [patch] Schema selection support|
|Reporter:||Alexander Frolkin (avf)||Labels:|
|Date Opened:||2010-12-14 11:14:24.000-0600||Date Closed:||2012-02-03 10:54:01.000-0600|
|Environment:||Attachments:||( 0) 20101216__issue18473.diff.txt|
( 1) schema.patch
|Description:||We use CDR with an Oracle backend, via ODBC. The CDR table exists inside a schema (called ASTERISKDBA), and there is a synonym (also called CDR) in the PUBLIC schema.|
When cdr_adaptive_odbc.c calls SQLColumns() to get a list of column names, the result set contains each column twice --- once for the ASTERISKDBA schema, and once for the PUBLIC schema. Obviously, this causes INSERTs to error.
This patch adds a "schema" configuration parameter which, when set, passes the schema name into SQLColumns().
Setting "schema => ASTERISKDBA" (or, for that matter, "schema => PUBLIC") fixes this problem in our environment.
<patch deleted from description>
****** ADDITIONAL INFORMATION ******
Disclaimer: I was asked to look at this problem by a colleague. I know nothing about CDR and very little about Asterisk. :-)
|Comments:||By: Tilghman Lesher (tilghman) 2010-12-15 14:45:42.000-0600|
Does the schema not need to be prefixed to the table name on insert/update? Or does it assume a default schema, if none is specified? Might a default schema ever have a permissions conflict on INSERT?
By: Alexander Frolkin (avf) 2010-12-16 04:10:20.000-0600
Ah, yes, you're right. It assumes PUBLIC, so it works for us because we have a synonym in PUBLIC, but in general, it does need to be prefixed to the table name in SQL statements.
By: Leif Madsen (lmadsen) 2010-12-16 10:46:37.000-0600
Confirmed, but it looks like there might be some additional work needing to be done on this patch. At the minimum there would need to be some documentation added to specify when this can be used.
By: Tilghman Lesher (tilghman) 2010-12-16 14:42:31.000-0600
Patch is built against 1.6.2, as I consider this a bug, and we patch the earliest version which has the feature.
EDIT: confirmed that the patch applies cleanly against 1.8 SVN, as well.