| 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-0600 | Date Closed: | 2011-11-18 17:38:15.000-0600 | ||
| Priority: | Blocker | Regression? | Yes | ||
| Status: | Closed/Complete | Components: | Core/AstDB | ||
| Versions: | 10.0.0-rc2 | Frequency of Occurrence | Constant | ||
| Related Issues: |
| ||||
| 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 : 1.2.3.4:5060:180:774:sip:774@4.3.2.1:5060 80 results found. pink*CLI> database get SIP Registry/774 Value: 1.2.3.4:5060:180:774:sip:774@4.3.2.1:5060 | ||||
| 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: {noformat} *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. {noformat} 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. | ||||