[asterisk-dev] Possible Call Event Logging (CEL) Bugs

[Nic Colledge]

Hi,

I've been playing around with CEL in asterisk trunk (SVN-Trunk-r236144) and have found some strange behaviour and am wondering if these are bugs.

I have the CEL table in a postgreSQL database the layout of which was taken from the cel_pgsql.conf file. I also added a "id" serial to use a primary key. The SQL create statement is included below.

CREATE TABLE cel
(
  uniqueid character varying(150) NOT NULL,
  linkedid character varying(150) NOT NULL,
  eventtime timestamp with time zone NOT NULL,
  eventtype integer NOT NULL,
  userdeftype character varying(100),
  cid_name character varying(100),
  cid_num character varying(100),
  cid_ani character varying(100),
  cid_rdnis character varying(100),
  cid_dnid character varying(100),
  exten character varying(100),
  context character varying(100),
  channame character varying(100),
  appname character varying(100),
  appdata character varying(200),
  accountcode character varying(100),
  peeraccount character varying(100),
  amaflag integer,
  userfield character varying(100),
  peer character varying(100),
  id serial NOT NULL
)
WITH (
  OIDS=FALSE
);

Anyway, when I use cel_pgsql.conf to connect to the database the "id" is always set to zero (which when it were a primary key caused a violation and made errors to that effect show up in the asterisk console).

Ok, so not the end of the world, I tried cel_adaptive_odbc.conf. Here the "id" serial is always set correctly by the database, but the following errors show up in the asterisk console:
[Dec 28 16:30:38] WARNING[1416]: cel_adaptive_odbc.c:574 odbc_log: CEL variable amaflag is not an integer.
[Dec 28 16:30:38] WARNING[1416]: cel_adaptive_odbc.c:574 odbc_log: CEL variable id is not an integer.

Any idea what's going on here? I'm working under the assumption that amaflag should be an int because the cel_pgsql.conf file comments say "amaflag (an int)".

Is there any way to make the pgsql backend ignore the ID (serial) column so that the database will sort its value out properly?
What are these other two errors from the adaptive ODBC backend?

I think it makes sense to have a primary key on this table, unless I'm missing something obvious I don't think one can be made from the other columns, can it?
Maybe it would be better to have asterisk make a extra field so that uniqueid + [somthing extra] can be used as a primary key? Of course I'm assuming it's not possible to use something that already exists when I suggest this.

Thanks in advance.

Regards,
Nic Colledge

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20091228/c75814ea/attachment.htm