[Home]

Summary:ASTERISK-04365: Documentation incorrect for new DB Functions
Reporter:Jean-Yves Avenard (jyavenard)Labels:
Date Opened:2005-06-07 00:03:13Date Closed:2011-06-07 14:11:53
Priority:TrivialRegression?No
Status:Closed/CompleteComponents:Functions/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:In the UPGRADING.txt in Asterisk it says:
* The applications DBGet and DBPut have been deprecated in favor of
 functions.  Here is a table of their replacements:

 DBGet(foo=family/key)        Set(foo=${DB(family/key)})
 DBPut(family/key=${foo})     Set(${DB(family/key)}=${foo})


I fail to see how DBGet and DBPut can be replaced by those two commands

If I want to create a new database entry:
DBPut(CFIM/200=300)
I will create the entry if it doesn't exist

With the new Set(${DB(CFIM/200)}=300) I get:
May 16 12:39:39 WARNING[11111]: func_db.c:54 function_db_read: DB: CFIM/200 not found in database.
   -- Executing Set("SIP/ipp100-1d45", "=300") in new stack
   -- Executing Playback("SIP/ipp100-1d45", "auth-thankyou") in new stack

as abviously DB(CFIM/200) always get replaced by its value which in this instance doesn't exist yet

the other serious problem is that DBGet used to automatically jump to prioriy n+101 if the entry didn't exist. Now I will do things like:
Set(temp=${DB(CFIM/200)})
which will set temp to "" instead of jumping to an error.

I wish DBGet and DBPut weren't removed their replacements are no good and can't be made to behave the same without serious re-work (like testing the returned entry is not null etc...)
Comments:By: Russell Bryant (russell) 2005-06-07 10:32:45

your Set syntax for setting a value is incorrect.

Set(${DB(CFIM/200)}=300)
should be ...
Set(DB(CFIM/200)=300)

As far as jumping to n+101 goes, we're working to deprecate all instances of that within Asterisk.  If you would like to check to see if a key exists, there is a DB_EXISTS function.

Please test this with the syntax correction and verify that it works for you.

Thanks
By: Michael Jerris (mikej) 2005-06-07 10:43:12

Is this wrong in the UPGRADING.txt??  If so, I will toss a patch out for it.
By: Jean-Yves Avenard (jyavenard) 2005-06-07 10:44:47

Thanks I will check

The syntax I used is what's described in the UPGRADE.txt documentation in asterisk.
By: Jean-Yves Avenard (jyavenard) 2005-06-07 10:48:59

Well, I must have dreamed it as it's not there anymore !
By: Michael Jerris (mikej) 2005-06-07 10:55:58

SO your issue is resolved, and the docs are fine, correct?
By: Tilghman Lesher (tilghman) 2005-06-07 11:13:56

As a note to the deprecation, the existing applications will probably be left, though printing a deprecated warning, into the 1.2 STABLE release of Asterisk.  They will probably be gone for the 1.4 STABLE release.  Note that 1.4 is way out into the future, probably at least 18 months away, so you have plenty of time to transition to the functions.
By: Russell Bryant (russell) 2005-06-07 23:17:39

I think UPGRADE.txt was incorrect at one point, but was fixed shortly after.

I am closing this as it seems to not be an issue.  Feel free to reopen if you find any bugs.