[asterisk-users] database queries from extensions.conf

[Julian Lyndon-Smith]

Atis Lezdins wrote:
> On Mon, Nov 24, 2008 at 8:01 PM, Julian Lyndon-Smith <asterisk at dotr.com> wrote:
>   
>> For me, the "best" is the curl function, along with res_config_curl.
>> Best of all worlds - pass a web query to *whatever* backend system you
>> want to implement. No messy ODBC drivers.
>>
>> It's really, really good stuff ;)
>>     
>
> However you probably can't use it for transactions within call
> workflow. For example:
>
>   
Yeah, you are right. However, I would never want a transaction to span 
user interaction. Yeuch.

Gather, verify, process. Done.

Customer Calls in
Record inbound call details.
Play prompt A
Record further details
Play prompt B
Record further details

We tie these three discrete transactions together by a guid.

Julian


> Customer calls in
> Start transaction
> Do query 1
> Play prompt A
> Do query 2
> Play prompt B
> Do query 3
> End transaction
>
> So, if customer hangs up in middle, you don't execute transaction.
> That's the thing how it should be done with ODBC or whatever :)
>
> Regards,
> Atis
>
>
>
>   
>> Julian.
>>
>> Jared Smith wrote:
>>     
>>> On Sun, 2008-11-23 at 00:47 -0500, Al Baker wrote:
>>>
>>>       
>>>> Quote "
>>>> The preferred method is to use func_odbc, which takes SQL queries and
>>>> builds custom dialplan functions from them. I've used it quite a bit,
>>>>
>>>> and am very happy with it."
>>>>
>>>> How can you be VERY HappY with  something that allows ONLY single statemts of SQL
>>>>
>>>>         
>>> My intention here is not to start a flamewar over which one is *best*,
>>> or worse to start arguing about who is right instead of what is right.
>>> You're absolutely correct in your assertion that func_odbc doesn't
>>> currently support multi-statement or transactional statements, which is
>>> obviously a limitation to some people.  As I pointed out in my other
>>> response to this thread this morning, Tilghman Lesher is working on
>>> that.  Feel free to look at his odbc_tx_support branch on the web at
>>> http://svn.digium.com/view/asterisk/team/tilghman/odbc_tx_support/, or
>>> to check it out via Subversion at
>>> http://svn.digium.com/svn/asterisk/team/tilghman/odbc_tx_support/
>>>
>>> One other way of working around the problem is to use stored procedures
>>> in the database.
>>>
>>> That being said, I guess I'll articulate my own personal reasons for
>>> preferring func_odbc, and leave it at that.
>>>
>>> 1) I like that my dialplan isn't tied to one particular database.  I've
>>> done a *lot* of database work in my short career, including being a
>>> sysadmin for one of the largest MySQL database installations in the
>>> world.  I *love* the fact that the ODBC abstraction layer means I can
>>> easily change my backend database from MySQL to PostgreSQL (or Oracle or
>>> SQL Server, heaven forbid!) at the drop of a hat.  I realize that might
>>> not be a big attraction for some, but for me it's a big plus.
>>>
>>> 2) I don't like the licensing mess associated with linking MySQL
>>> directly to Asterisk.  I'm sure there are a few people on the list that
>>> really enjoy the convoluted logic of tip-toeing the licensing minefield
>>> of linking (dual-licensed) Asterisk with (dial-licensed) MySQL, but I
>>> prefer to avoid the minefield altogether and use ODBC.
>>>
>>>
>>>
>>>       
>> ______________________________________________________________________
>> This email has been scanned by the MessageLabs Email Security System.
>> For more information please visit http://www.messagelabs.com/email
>> ______________________________________________________________________
>>
>> _______________________________________________
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> asterisk-users mailing list
>> To UNSUBSCRIBE or update options visit:
>>   http://lists.digium.com/mailman/listinfo/asterisk-users
>>
>>     
>
>
>
>   


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________