[asterisk-users] Asterisk and Dabatase

[Mike]

Thanks, I appreciate getting the update on 1.6 with regards to the DB
functions (and, for that matter, on the hints too).  Wouldn't using "MYSQL
Disconnect" handle the ressources as well (if, of course, called when
needed)?

About 1.6, would you know if the SIPPEER func now support sip realtime?
It's a shame Asterisk is (was?) developped with mismatches between .conf
functionality and realtime ones.

Regards,

Mike



-----Original Message-----
From: asterisk-users-bounces at lists.digium.com
[mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of Tilghman
Lesher
Sent: Sunday, December 21, 2008 12:49
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] Asterisk and Dabatase

On Sunday 21 December 2008 09:03:29 Mike wrote:
> I've explored two ways of working with the database, as far as dialplan
> goes.  The first was using realtime, as described in the wiki, to store
the
> dialplan.  This became very messy very quickly, as an SQL database isn't a
> great support for the dialplan. It's (relatively) hard to modify, and if
> your goal is to build your own Web portal (which was my goal) you're stuck
> making the portal code very complexe to accommodate the messy dialplan.
>
> What I went with was the complete opposite.  I build the dialplan in the
> conf files, but everytime I refered to something dynamic, I called an SQL
> function (see MYSQL cmd for Asterisk).  This made the dialplan more
> complexe (lot's of call to MYSQL) but it's more easily changed (since it's
> still text) and the Web portal is much readable since everything relies a
> well-designed relational DB instead of the dialplan realtime database.

This is exactly what I recommend to people, and I'm happy to see that others
are heading in this direction, even if it's not with the tools that I've
developed for this purpose.

> But there are donwsides to that too: MYSQL down means my VoIP server is
> also down (which never actually happened, but it could).  And, as I said,
> the .conf file is a lot more complexe

I've tried to address several of the complaints about func_odbc in the 1.6.x
version.  Specifically, func_odbc supports multirow queries, separation of
read and write operations, and automatic failover between database handles.
One of the other advantages that func_odbc has over the MYSQL command is
that resources are automatically deallocated when a channel hangs up.  When
the MYSQL command was originally written, it did not have the advantage of
some of the channel infrastructure that we now have, and therefore it could
not automatically destroy resources when they were no longer relevant.

-- 
Tilghman

_______________________________________________
-- 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