I think this is already the intended behavior of the db app.

under insert it does the following:

sql = switch_mprintf("delete from db_data where realm='%q' and data_key='%q'", argv[1], argv[2]);

then:

sql = switch_mprintf("insert into db_data (hostname, realm, data_key, data) values('%q','%q','%q','%q');", globals.hostname, argv[1], argv[2], argv[3]);


If you are getting differing results, can you report it under Jira and post examples on how to reproduce using GIT HEAD so we can get to the bottom of it.  There must be a bug if this is happening.


Also .. Yiftach Golan.

Why do you continue to make childish comments?  Especially on other people's thread.  Asking people to go offline with you so you can feed them FUD about how we don't listen to people, meanwhile here we are every day answering hundreds of emails.    Do you really not understand?  I am seriously trying to help you here.  You need to learn a few things about etiquette to work in a community setting.  There is a difference between saying your opinion and arguing a moot point into the ground when its not even your thread......  Being annoyed because we want to use Jira which is the intended resource for development and issue tracking makes no sense and is a bit selfish.  If we are going to share our project with you, the least you can do is follow our minimal set of guidelines to make it easier for a handful of people to manage a community of several thousand people.....

=/






On Sat, Nov 17, 2012 at 7:42 PM, Scott <8f27e956@gmail.com> wrote:
Are there reasons why the function 'hash' (non-persistent storage) and function 'db' (persistent storage) share a look-a-like user interface (e.g. select/insert/delete) but do not work-a-like.  In particular, in 'hash', insert overwrites an identical realm/data_key pair whereas 'db' , in so far as I can tell, just blindly adds, and adds, adds, the insert(s).  However, the 'db' select method returns one record only even if the db has accumulated many realm/data_key records, including data_value duplicates. 

NOTWITHSTANDING reasons-unknow-to-me, a remedy to harmonize the non-persistent 'hash' with the persistent 'db'  I *think* is straight forward ...

(1) At the call_limit.db schema-level, a one-time create UNIQUE COMPOUND index, as follows,

CREATE UNIQUE INDEX IF NOT EXISTS 'idx_db_data_HostRealmDK' ON 'db_data' ('hostname','realm','data_key');

(1) At the c-language embedded SQL string-level,

change the existing INSERT to be the following,

INSERT OR REPLACE INTO db_data (hostname,realm,data_key,data) VALUES (%s,%s,%s,%s);

The index will help speed UP the reads.  Neither change is "exotic" and should be portable across standard sql implementations.

;-) ... thoughts ?

Thanks,




_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org




--
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
Twitter: http://twitter.com/FreeSWITCH_wire

AIM: anthm
MSN:anthony_minessale@hotmail.com
GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888@conference.freeswitch.org
googletalk:conf+888@conference.freeswitch.org
pstn:+19193869900