Summary:	ASTERISK-04252: [patch] add new realtime function realtime_direct
Reporter:	Gregory Hinton Nietsky (irroot)	Labels:
Date Opened:	2005-05-21 13:17:58	Date Closed:	2011-06-07 14:05:17
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Resources/res_features
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) func_rtdb.c.with_update ( 1) realtime_indel.patch
Description:	this will allow direct quries to the realtime database typicaly UPDATE/DELETE/INSERT by passing a SQL query directly to the underlying engine. this allowed me to redo app_dbodbc.c to work with realtime both are attached please note obtaining a disclaimer for app_dbodbc.c will be possiby problematic
Comments:	By: Olle Johansson (oej) 2005-05-21 14:52:23 Realtime is not designed to be SQL specific, it is designed to also handle other data storage sources, like possibly LDAP. This breaks that design. I don't think it fits within the current Asterisk architecture. Please read bug guidelines, you haven't mentioned if you have disclaimed this code. By: Gregory Hinton Nietsky (irroot) 2005-05-21 15:12:10 sure realtime is backend independant allowing any database architechture to create a res_config_<type>.so module and go from there currently just about any SQL DB is supported via ODBC or nativly ... LDAP will require a LDAP schema to be put together and a config hung off this ... as there is currently NO way to INSERT/DELETE/UPDATE data what i propose is a start to support LDAP do as follows ast_direct_realtime("OU=astdb","delete:CallForward/1234"); the function in res_config_ldap will need to parse and deal with the syntax ... there are other examples of SQL specific bits elsewhere ... bear in mind that a backend need not define the direct method ... i am busy converting func_db.c to use ODBC realtime to store database entries relying on this direct method to update/add entries By: Michael Jerris (mikej) 2005-05-21 15:22:16 I think the right way to do this is to build insert\delete functionality into realtime, not loosing the nice abstraction to storage we have now.  If you do an update in realtime now won't it do an insert if it is on there?? By: Brian West (bkw918) 2005-05-21 18:19:27 Considering I wrote app_dbodbc.c ... its not problematic at all! ;) /b By: Brian West (bkw918) 2005-05-21 18:21:30 * LookupCIDName and LookupBlacklist added by * Rob Fugina <robf@geekthing.com> 01/13/2005 * * try once reconnect to database if connection was lost * by Jukka Laaksola <jukka@netland.fi>  04/12/2005 those are so trivial its not EVEN funny.  Still shouldn't be an issue. /b By: Gregory Hinton Nietsky (irroot) 2005-05-21 19:05:32 im renaming this all from ODBC to RTDB ... ok there is a working ODBC [to be renamed] function that is a unashamed rip of func_db and use of the functions i added to app_dbodbc ... ill be putting togethere a realtime_delete/realtime_insert function in the next day or so i certainaly think these should be there to make realtime more flexiable ... it would be pretty neat been able to create a new "friend" via a IVR directly ... right now im only using it as one would use DB. ill extend the syntax to allow looking poking and proding of all realtime databases ... RTDB(return/field:equate@rtdb) RTDB(password/mailbox:user@voicemail) will return/set the mailbox password where mailbox=user in the voicemail database ill be keeping the format of DB for use with the default astdb structure By: drmac (drmac) 2005-05-21 22:23:05 I have to agree with oej's first post on this. this patch doesn't seem geared to "abstraction" of db functionality. Not sure where you get the idea that there is no UPDATE function (ast_realtime_update rings a bell..) but just because there is no INSERT/DELETE functionality at this time, doesn't mean it can't be added. In fact, ASTERISK-3943 will most likely introduce the need for ast_realtime_insert and ast_realtime_delete. By: Gregory Hinton Nietsky (irroot) 2005-05-22 03:55:21 the update is indeed there ... and functional ... the direct call allows you to be more creative with update not a good argument by any means ... i am busy with a insert and delete that you will find acceptable ... and once i have extended ODBC to RTDB functionality initialy all i want is a alternative to astdb in the dialpalan once functional db.c can be changed to use the realtime engine ... ;extconfig.conf astdb => odbc,Asterisk,astdb By: Gregory Hinton Nietsky (irroot) 2005-05-22 06:02:15 ... there it is a patch to realtime that allows deletes and inserts without breaking any abstraction also find the start of the RTDB function that only works as a replacement for DB at this point but can be extended as needed ... By: Gregory Hinton Nietsky (irroot) 2005-05-22 09:24:17 here is a example of usage to go with the new func ive just uploaded first the schema for the astdb bits Column |  Type  |                   Modifiers --------+--------+------------------------------------------------ id     | bigint | not null default nextval('astdb_id_seq'::text) family | text   | key    | text   | value  | text   | Indexes:    "astdb_pkey" PRIMARY KEY, btree (id)    "astkey" UNIQUE, btree (family, "key")    "astfamily" btree (family) traditional astdb goodies ... [macro-authuser] exten => s,1,GotoIf($[${ARG1} = 9]?admin) exten => s,n,VMAuthenticate(${ARG1}@6,t) exten => s,n(admin),SET(UPASS=${RTDB(Setup/AdminPass)}) exten => s,n,GotoIf(${EXISTS(${UPASS})}?:noadmin) exten => s,n,Authenticate(${UPASS}) exten => s,n+1(noadmin),Read(UPASS|agent-pass) exten => s,n,SET(RTDB(Setup/AdminPass)=${UPASS}) exten => s,n,SayDigits(${UPASS}) update example ... [macro-adminpasschange] exten => s,1,SET(UPASS=${RTDB(Setup/AdminPass)}) exten => s,n,GotoIf(${EXISTS(${UPASS})}?:nopass) exten => s,n,Authenticate(${UPASS}) exten => s,n,Read(APASS|agent-pass) exten => s,n,SET(RTUP(Setup/AdminPass)=${APASS}) exten => s,n(nopass),Hangup extensions to modify rtdb goodies ... [macro-changevmpass] exten => s,1,SET(UPASS=${RTDB(password@voicemail:mailbox/${CALLERIDNUM})}) exten => s,n,GotoIf(${EXISTS(${UPASS})}?:nopass) exten => s,n,Authenticate(${UPASS}) exten => s,n,Read(APASS|agent-pass) exten => s,n,SET(RTUP(password@voicemail:mailbox/${CALLERIDNUM})=${APASS}) exten => s,n(nopass),Hangup By: drmac (drmac) 2005-05-22 12:22:19 all of your examples seem to be centered around app_authenticate. why not just realtime-enable app_authenticate? i'm not one of the core programmers, but there are some significant disadvantages to using astdb in an external database which the core programmers know all about. By: Michael Jerris (mikej) 2005-06-27 22:50:04 brian-  Can you review this please. By: Olle Johansson (oej) 2005-07-18 06:47:54 Gentle reminder from housekeeping: Seems like we're waiting for feedback from bkw918. Brian, if you don't have the time, please indicate so. /O By: Brian West (bkw918) 2005-07-25 23:00:06 doh.. I think its a good idea.. but I think it might need more eyes on it. By: Brian West (bkw918) 2005-07-25 23:00:21 doh.. I think its a good idea.. but I think it might need more eyes on it. By: Kevin P. Fleming (kpfleming) 2005-08-22 16:26:45 Review of realtime_indel.patch: 1) The documentation comments for the new functions in config.h are completely wrong; they document parameters that don't exist and the descriptions of what they do are not correct either. 2) There is a tremendous amount of code duplication in insert_odbc and delete_odbc (setting up the SQL statements and parameters, etc). Can you refactor this code to make it more efficient please? By: Kevin P. Fleming (kpfleming) 2005-08-22 16:38:56 Review of func_rtdb.c: 1) There are formatting problems all over this file; please review the coding guidelines. 2) Inconsistent help text: RTDB requires an argument, RTDB(<family>/<key>) RTDB requires an argument, RTDB([<field>@database:]<family>/<key>) RTDB requires an argument, RTDB(<family>/<key>)=<value> 3) The long format help descriptions for the functions have many grammatical errors and don't make much sense. 4) Please explain more explicitly the difference between writing a value with RTDB() (which updates the database) and RTUP() (which is a bad function name choice regardless). By: Michael Jerris (mikej) 2005-08-28 00:00:41 Bug suspended until updates are ready.  Please re-open when updates are ready.  Also, I noticed that there is no mention of a disclaimer on this bug.  We will need a disclaimer submitted before this bug can be re-opened (if you do not already have one on file with digium).