[asterisk-dev] Violent Objections? CDR dst/dcontext probs in 1.4+ when a macro is involved.
Tilghman Lesher
tilghman at mail.jeffandtilghman.com
Tue Jul 3 14:55:13 CDT 2007
On Tuesday 03 July 2007 13:53, Steve Murphy wrote:
> So, it would appear that the methodology would go something like
> this:
>
> Define your own personal CDR database, with the fields as you would
> wish them.
> Name the fields in such a way so as not to conflict with the existing
> CDR field names (don't use clid, src, channel, dst, etc.). I'd assume
> that
> if you do use the same names, it's automatically a tie from the CDR
> to the DB, and you'll not be able to drop or modify those fields. So,
> using different names in the DB fields would be the most general way
> to handle this. You can later pretty much handle anything that might
> happen with some swift, easy, config file and dialplan changes. I
> guess an analogy would be patch-panels in the wiring world. Why use
> patch-panels? What a waste! Think of all the money you could save if
> you just wired direct end-to-end and eliminated patch-panels! Or...?
No, I think you've missed it. The reason why this module is adaptive is
if you drop a column from (or add a column to) an existing table, all
you need to do is to send a reload event to the module and it will adapt
to the new schema. In other words, if you drop the dst column from the
table, it will adapt and the new records simply won't try to insert a
dst column. If you add a column 'foo' and you define CDR(foo), that
column will similarly start to show up in whatever cdr table you
defined.
There isn't even a limit to how many tables you insert to. So, for
example, it's perfectly doable to configure one table for Oracle, one
for MS SQL Server, and two for MySQL (each table in MySQL having
a different schema) and it will adapt to each and you will get 4 CDRs
(one per table) for each call.
> How do I drop builtin CDR fields? I assume all I have to do is not
> alias them, or have the same name in the DB.
Just drop them and 'module reload cdr_adaptive_odbc.so'. That's all.
If you've defined an alias, no worries there, either. It will only
"see" an alias if the corresponding column exists in the table. You can
have 100 aliases that point to nonexistent columns and cdr_adaptive_odbc
will simply ignore them.
--
Tilghman
More information about the asterisk-dev
mailing list