Summary: | ASTERISK-11101: SQL Insert Support For func_odbc | ||
Reporter: | Gregory Hinton Nietsky (irroot) | Labels: | |
Date Opened: | 2007-12-22 06:47:33.000-0600 | Date Closed: | 2007-12-23 11:29:12.000-0600 |
Priority: | Major | Regression? | No |
Status: | Closed/Complete | Components: | Functions/func_odbc |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ( 0) func_odbc_insert.patch | |
Description: | here is a patch that i have been using for quite a while and find invaluable. 1)should the write fail attempt the insert command 2)allow a insert command to set various bits and pieces without read/write concider it a small Xmas gift ;) ****** ADDITIONAL INFORMATION ****** i use monitor to store files in the structure <DATE>/<EXTEN>/<UNIQUEID>-<CALLLEG> where callleg is the "hop count" stopmonitor stops on each transfer and restarts so one call is broken up into multiple hops ... to keep track of this all i have a table with fields for uniqueid/callleg/exten i use the insert feature to do the adding ... func_odbc.conf [LOG] dsn=Asterisk insert=INSERT INTO calllog (uniqueid,callleg,exten) VALUES ('${ARG1}',${ARG2},'${VAL1}') SET(ODBC_LOG(${UNIQUEID},${CALLLEG})=${EXTEN}) [QUEUE] dsn=Asterisk read=SELECT ${ARG1} FROM queue_members WHERE queue_name='${ARG2}' AND interface='${ARG3}' write=UPDATE queue_members SET ${ARG1} = '${VAL1}' WHERE queue_name='${ARG2}' AND interface='${ARG3}' insert=INSERT INTO queue_members (queue_name,interface,penalty,defpenalty) VALUES ('${ARG2}','${ARG3}','${VAL1}','${VAL1}') SET(ODBC_QUEUE(penalty,${ARG1},${IFACE})=${PENALTY}) | ||
Comments: | By: Tilghman Lesher (tilghman) 2007-12-23 11:28:49.000-0600 I'll note that you can do the same thing by using dialplan code: n,Set(ODBC_FOO(foo)=123) n,GotoIf($[${ODBCROWS} >= 0]?done) n,Set(ODBC_FOOINSERT(foo)=123) n(done),NoOp and it's a lot more versatile by allowing the dialplan creator the option to decide how the failover should happen. I know there's a lot of push and pull as to how complex we should make the API, but this is one area that I think we ought to keep on the simple side, to avoid a great deal of confusion. |