[asterisk-users] database queries from extensions.conf

[Atis Lezdins]

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:

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
>



-- 
Atis Lezdins,
VoIP Project Manager / Developer,
IQ Labs Inc,
atis at iq-labs.net
Skype: atis.lezdins
Cell Phone: +371 28806004
Cell Phone: +1 800 7300689
Work phone: +1 800 7502835