Summary:ASTERISK-18886: database show fails for FOO/BAR/BAZ with sqlite where BDB succeeds
Reporter:Tony Vroon (chainsaw)Labels:
Date Opened:2011-11-18 07:13:28.000-0600Date Closed:2011-11-18 17:38:15.000-0600
Versions:10.0.0-rc2 Frequency of
must be completed before resolvingASTERISK-18847 Asterisk 10.0.0 Release Blockers
Environment:Linux pink 3.0.4-hardened-r4 #1 SMP Wed Oct 26 14:07:12 BST 2011 x86_64 Dual-Core AMD Opteron(tm) Processor 2218 AuthenticAMD GNU/Linux [ebuild R #] net-misc/asterisk-10.0.0_rc2 USE="caps curl dahdi http iconv jabber jingle mysql newt snmp span speex srtp syslog vorbis -ais -alsa -bluetooth -calendar -debug -doc -freetds -gtalk -ldap -lua -odbc -osplookup -oss -portaudio -postgres -radius -samples -sqlite -sqlite3 -static -usb" 0 kB Attachments:( 0) db_patch4.diff
( 1) issueA18886-sqlite_key_4.patch
Description:Regression in 10 compared to 1.8: database show will claim no results for a FOO/BAR/BAZ database key, while BAZ is listed for FOO/BAR. This appears to be related to the switch from BDB to SQLite.

pink*CLI> database show SIP/Registry/774
0 results found.

pink*CLI> database show SIP/Registry
(79 irrelevant results snipped)
/SIP/Registry/774                                 :
80 results found.

pink*CLI> database get SIP Registry/774
Comments:By: Gregory Hinton Nietsky (irroot) 2011-11-18 08:03:30.657-0600

Small patch that gets it working.

By: Leif Madsen (lmadsen) 2011-11-18 08:06:25.011-0600

Added Terry Wilson to watchers list. Would like to get his opinion on this one. I consider this one a 10.0.0 blocker.

By: Gregory Hinton Nietsky (irroot) 2011-11-18 08:15:52.907-0600

Take wild card into account for only the usage "foo/bar" "foo/bar baz" will not match wildcard.

foo/bar -> /foo/bar/%
foo/bar baz -> /foo/bar/baz

By: Gregory Hinton Nietsky (irroot) 2011-11-18 08:59:29.163-0600

This is the more correct patch wdoekes2 has a more complete version

By: Walter Doekes (wdoekes) 2011-11-18 09:02:34.245-0600

And we both kept the redundant parentheses in the if. Fixed now.

By: Terry Wilson (twilson) 2011-11-18 14:29:00.397-0600

Changing the queries to include OR statements and failing on binding would not be my favorite means of fixing this. There was a plan to eventually make the astdb realtime-capable and realtime doesn't support ORs in queries. On IRC, tilghman stated that we could always store the family/subfamily with a trailing slash and just use LIKE queries and trim the trailing slash when displaying the results.

By: Terry Wilson (twilson) 2011-11-18 16:27:07.314-0600

Here is the help output for the database CLI commands:
*CLI> core show help database show
Usage: database show [family [subfamily]]
      Shows Asterisk database contents, optionally restricted
      to a given family, or family and subfamily.

*CLI> core show help database put
Usage: database put <family> <key> <value>
      Adds or updates an entry in the Asterisk database for
      a given family, key, and value.

*CLI> core show help database deltree
Usage: database deltree <family> [subfamily]
      Deletes a family or specific subfamily within a family
      in the Asterisk database.

*CLI> core show help database del
Usage: database del <family> <key>
      Deletes an entry in the Asterisk database for a given
      family and key.

*CLI> core show help database get
Usage: database get <family> <key>
      Retrieves an entry in the Asterisk database for a given
      family and key.

*CLI> core show help database showkey
Usage: database showkey <subfamily>
      Shows Asterisk database contents, restricted to a given key.

Note that database {get,put,del,showkey} operate on "keys" (showkey says <subfamily>, but the description and its behavior make it clear that <key> is the correct nomenclature). database {show,deltree} operate on family and subfamily. database put defines the <value> which is the value associated with a particular family[/subfamily]/key.

So, given the string FOO/BAR/BAZ = 1, 1 is obviously the value, BAZ *has* to be the key (since there is *always* a key), and the family/subfamily is a little ambiguous. It could family = FOO, subfamily = BAR; or it could be family = FOO/BAR. But, *no matter how* you interpret the family and subfamily, the documentation of the commands shows that "database show FOO/BAR/BAZ" would not match the family/subfamily because BAZ is the key. Therefor, Asterisk 10 properly adheres to the documentation, regardless of the undocumented behavior of 1.8. The proper way to get the value of FOO/BAR/BAZ is to use "database get FOO/BAR BAZ".

Given that 10 adheres to the documentation, and that the behavior of 1.8 did not, I would not classify this as a regression--merely an undocumented behavior change. Changing undefined behavior is by definition not a regression.

With all of that said, tilghman just came up with a patch that looks like something I could accept...so, more to come.

By: Tony Vroon (chainsaw) 2011-11-18 16:53:51.016-0600

Note that this "undocumented behaviour" has worked since 1.2; all the way through 1.4, 1.6.0, 1.6.1, 1.6.2 & 1.8 before failing in 10. This is a regression that is going to break existing dial plans.

By: Terry Wilson (twilson) 2011-11-18 17:53:31.623-0600

Again, changes in undefined behavior cannot be considered *regressions*. It is pedantic, but true. With that said, Tilghman has a patch committed, and we are working on fixing the documentation to be more descriptive of what the behavior is. Please note that "database show" is a CLI command and itself wouldn't break dialplans. I do not believe the DB dialplan functions would be affected.