> >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of >Steven Critchfield >Sent: Thursday, 2 October 2003 11:58 AM >To: [EMAIL PROTECTED] > >On Wed, 2003-10-01 at 19:19, John Todd wrote: >> At 9:56 AM +1000 10/2/03, Ben Lear wrote: >> >[snip] >> >Let the flaming begin :D >> > >> >Ben. >> > >> >PS: I would consider donating my ODBC wrapper code/time to >the "Lets >> >get this database crap sorted once and for all cause" if enuff >> >interest is shown. >> > >> >> Yes, I would have quite an interest in making a generic toolkit >> interface for Asterisk to talk with databases. Currently, I >am locked >> into writing hacks to get to database information, or >building config >> files with similar hacks. Even just a few simple routines >to replace >> "DBGet" and "DBPut" with something that talks to an external system >> would be welcome; no need to replace the whole system all at one >> time... > >Not that this solves the other part of the problem, but did >you look into PGSQL commands in asterisk? It allows you full >database access from the extension logic. > >Now for the interesting part. I mentioned this once before, >but shouldn't we make a SQL resource and then use it to make >the connections to the database? > >I would prefer this solution especially if ODBC was to be used >since you could prioritize your SQL commands and those with >low priority could go to the lower end of the list in the >event of database overrun. Take for instance CDR events as >having lower priority as they are written at the completion of >the call and no one is being impacted. Then say your voicemail >app could run medium to high priority since you would have a >user being impacted. Also with all the queries going through >a single point, you only have less chances of a connection >timing out and you don't have to worry about how many users >you appear to be to any proprietary DB back end. Also later on >adding SQL support to a app is not much more than issuing the >correct res_sql_ commands instead of linking in anything else. > >What is anyone elses thought about going the resource route?
I think the reasource idea fits into the ODBC/Database Toolkit concept perfectly. The whole point is to remove the need to worry about how blah blah database handles such and such. You just call res_sql_prepareqry().....res_sql_execqry() etc. *What* gets put in the database is a whole other issue and not really within the scope of what I'm trying to flesh out. As far as performance/priority requirements go there are a number of ways to get around the performance issues(Connection Queues/Pools etc) though these can be worked on *at some later time*, the immediate need is to get something implimented with an interface that remains fairly stable. As ODBC/SQL is a mature and well known standard, coming up with an Asterisk SQL reasource API should be a straight forward execercise. I'm going to do a little more code crawling to see how this might all come together. Keep the ideas comming :) Cheers, Ben. _______________________________________________ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev
