Details

    • Type: New Feature New Feature
    • Status: Closed
    • Severity: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Target Release Version/s: None
    • Component/s: Applications/General
    • Labels:
      None
    • Mantis ID:
      2144
    • Regression:
      No

      Description

      I coded a new Asterisk application called MYSQL which
      is similar to application PGSQL but works with MYSQL.
      The syntax of the application is:

      -------------------
      *CLI> show application Mysql

      = Info about application 'MYSQL' =

      [Synopsis]:
      Do several mySQLy things

      [Description]:
      MYSQL(): Do several mySQLy things
      Syntax:
      MYSQL(Connect connid dhhost dbuser dbpass dbname)
      Connects to a database. Arguments contain standard MySQL parameters
      passed to function mysql_real_connect. Connection identifer returned
      in $

      {var}
      MYSQL(Query resultid ${connid} query-string)
      Executes standard MySQL query contained in query-string using established
      connection identified by ${connection_identifier}. Result of query is
      is stored in ${var}

      .
      MYSQL(Fetch fetchid $

      {resultid} var1 var2 ... varn)
      Fetches a single row from a result set contained in ${result_identifier}.
      Assigns returned fields to ${var1} ... ${varn}. ${statusvar} is set TRUE
      if additional rows exist in reseult set.
      MYSQL(Clear ${resultid}

      )
      Frees memory and datastructures associated with result set.
      MYSQL(Disconnect $

      {connid}

      )
      Disconnects from named connection to MySQL.

      *CLI>
      -------------------

      I am attaching the source file and the new applicatins Makefile for the change. My disclaimer is on file with
      Digium.

        Activity

        Hide
        twisted added a comment -

        I would suggest we make a crack at some sort of external data storage/retrieval framework, that we could just plug in modules for , and based on the calls in the dialplan logic, we determine what type of db we're connecting to, assuming we have that module installed..

        something like... res_database, and called from the cli/extensions.conf similar to the method you are using above, except we could use options to specify the db type -

        Database([action][|query string[|dbtype]])

        could prove useful, and being 'pluggable' theoretically our access methods are unlimited...

        Show
        twisted added a comment - I would suggest we make a crack at some sort of external data storage/retrieval framework, that we could just plug in modules for , and based on the calls in the dialplan logic, we determine what type of db we're connecting to, assuming we have that module installed.. something like... res_database, and called from the cli/extensions.conf similar to the method you are using above, except we could use options to specify the db type - Database( [action] [|query string [|dbtype] ]) could prove useful, and being 'pluggable' theoretically our access methods are unlimited...
        Hide
        constfilin added a comment -

        1. just when I said that I didn't have to need any patches to original source,
        I ran into a bug . The problem was in scenario when SQL query does not
        return any rows (e.g. INSERT or UPDATE).

        Now MYSQL() now handles these scenarios correctly. Moreover, for
        INSERTs, UPDATEs and DELETEs there is no need to call MYSQL(Clear ...)
        after MYSQL(Query).

        I am attaching new app_sql_mysql.c for completeness. If anyone will
        need MYSQL then (s)he can pick it up here.

        2. Yes, something like "Database([action][|query string[|dbtype]])" would be
        good. Another improvement must be done for caching SQL connection
        handles. Right now a new SQL connection opens and closes on each channel.
        this is ineffective.

        3. Until we are done with "Database", we can put MYSQL into -addons. But

        • eventually - it is your call.

        Thanks!

        -c

        Show
        constfilin added a comment - 1. just when I said that I didn't have to need any patches to original source, I ran into a bug . The problem was in scenario when SQL query does not return any rows (e.g. INSERT or UPDATE). Now MYSQL() now handles these scenarios correctly. Moreover, for INSERTs, UPDATEs and DELETEs there is no need to call MYSQL(Clear ...) after MYSQL(Query). I am attaching new app_sql_mysql.c for completeness. If anyone will need MYSQL then (s)he can pick it up here. 2. Yes, something like "Database( [action] [|query string [|dbtype] ])" would be good. Another improvement must be done for caching SQL connection handles. Right now a new SQL connection opens and closes on each channel. this is ineffective. 3. Until we are done with "Database", we can put MYSQL into -addons. But eventually - it is your call. Thanks! -c
        Hide
        constfilin added a comment -

        Yet another improvement to MYSQL application. Now MYSQL uses mutexes to avoid 2 threads changing its static variables at the same time.

        Show
        constfilin added a comment - Yet another improvement to MYSQL application. Now MYSQL uses mutexes to avoid 2 threads changing its static variables at the same time.
        Hide
        Brian West added a comment -

        this will have to go in addons I suspect.

        Show
        Brian West added a comment - this will have to go in addons I suspect.
        Hide
        Mark Spencer added a comment -

        Added to asterisk-addons, thanks!

        Show
        Mark Spencer added a comment - Added to asterisk-addons, thanks!

          People

          • Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development