pyst-users

[Pyst-users] functions for database access

[<jpm...@gm...>]

hi,

i'm a newbie to python but i've been working with asterisk since quite
some time. today i've written some functions for the Manager class to
implement database access. maybe you're interested...

    def DBGet(self, family, key):
        response = self.command('database get %s %s' % (family, key))
        if response.has_header('Value'):
            return response['Value']
        else:
            raise ManagerException('Database entry not found')

    def DBPut(self, family, key, value):
        response = self.command('database put %s %s %s' % (family, key,
value))
        if 'Updated database successfully' in response.data:
            return True
        else:
            raise ManagerException('Database update was not successful')

    def DBDel(self, family, key):
        response = self.command('database del %s %s' % (family, key))
        if 'Database entry removed' in response.data:
            return True
        if 'Database entry does not exist.' in response.data:
            raise ManagerException('Database entry does not exist.')
        else:
            raise ManagerException('Database update was not successful')

    def DBDelTree(self, family):
        response = self.command('database deltree %s' % family)
        if 'Database entries removed.' in response.data:
            return True
        else:
            raise ManagerException('Database update was not successful')

these functions should be pretty much self-explaining. like i've said,
probably quite primitive, but it's working. i didn't use the "Action:
DBGet" way because event handling is less compact than using the CLI
commands. anyway, i also wrote something in that direction in order to
understand event handling...

#    def DBGet(self, family, key):
#        """Return a value from the Asterisk database"""
#        def handle_DBGetResponse(event, manager):
#            returned_values[event.get_action_id()] =
event.get_header('Val')
#
#        returned_values = {}
#        self.register_event('DBGetResponse', handle_DBGetResponse)
#        response = self.send_action({'Action':'DBGet', 'Family':family,
'Key':key})
#        if response['Response'] == 'Error':
#            raise ManagerException(response['Message'])
#        action_id = response['ActionID']
#        while action_id not in returned_values:
#            pass
#        self.unregister_event('DBGetResponse', handle_DBGetResponse)
#
#        return returned_values[action_id]

this function includes an event handler to which it subscribes in order
to fetch the database value. in the while loop, it waits for a value to
be returned.

i haven't implemented timeouts so far. please let me know your opinion.

regards j.

Re: [Pyst-users] functions for database access

[Matthew N. <mni...@di...>]

Jan,

I don't think using self.command directly is the correct way to 
implement this feature.  Also I don't think automatically handling 
events for the user is the right way to do it either.

I think pyst should be fairly low level and only provide an convent 
interface to AGI and the Manager.  Also on the flip side, pyst should 
not be designed to prevent the user from building a layer of abstraction 
on top of it either.

Either way, pyst 0.3 will make it easier to do these things in a more 
straightforward manner.  No ETA on that though, for an idea of what it 
might look like, check out astxx (http://matt-land.com/astxx).

Jan Müller wrote:
> hi,
> 
> i'm a newbie to python but i've been working with asterisk since quite
> some time. today i've written some functions for the Manager class to
> implement database access. maybe you're interested...
> 
>     def DBGet(self, family, key):
>         response = self.command('database get %s %s' % (family, key))
>         if response.has_header('Value'):
>             return response['Value']
>         else:
>             raise ManagerException('Database entry not found')
> 
>     def DBPut(self, family, key, value):
>         response = self.command('database put %s %s %s' % (family, key,
> value))
>         if 'Updated database successfully' in response.data:
>             return True
>         else:
>             raise ManagerException('Database update was not successful')
> 
>     def DBDel(self, family, key):
>         response = self.command('database del %s %s' % (family, key))
>         if 'Database entry removed' in response.data:
>             return True
>         if 'Database entry does not exist.' in response.data:
>             raise ManagerException('Database entry does not exist.')
>         else:
>             raise ManagerException('Database update was not successful')
> 
>     def DBDelTree(self, family):
>         response = self.command('database deltree %s' % family)
>         if 'Database entries removed.' in response.data:
>             return True
>         else:
>             raise ManagerException('Database update was not successful')
> 
> these functions should be pretty much self-explaining. like i've said,
> probably quite primitive, but it's working. i didn't use the "Action:
> DBGet" way because event handling is less compact than using the CLI
> commands. anyway, i also wrote something in that direction in order to
> understand event handling...
> 
> #    def DBGet(self, family, key):
> #        """Return a value from the Asterisk database"""
> #        def handle_DBGetResponse(event, manager):
> #            returned_values[event.get_action_id()] =
> event.get_header('Val')
> #
> #        returned_values = {}
> #        self.register_event('DBGetResponse', handle_DBGetResponse)
> #        response = self.send_action({'Action':'DBGet', 'Family':family,
> 'Key':key})
> #        if response['Response'] == 'Error':
> #            raise ManagerException(response['Message'])
> #        action_id = response['ActionID']
> #        while action_id not in returned_values:
> #            pass
> #        self.unregister_event('DBGetResponse', handle_DBGetResponse)
> #
> #        return returned_values[action_id]
> 
> this function includes an event handler to which it subscribes in order
> to fetch the database value. in the while loop, it waits for a value to
> be returned.
> 
> i haven't implemented timeouts so far. please let me know your opinion.
> 
> regards j.
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Pyst-users mailing list
> Pys...@li...
> https://lists.sourceforge.net/lists/listinfo/pyst-users

-- 
Matthew Nicholson
Digium

Re: [Pyst-users] functions for database access

[<jpm...@gm...>]

Matt,

thanks for your feedback. Like I've said, just quick and dirty. At least
to my knowledge (searching the web for a day), so far, there are close
to zero examples for the usage of pyst, so I meant to contribute a
"how-to find back an event associated to an action" (identified by an
action_id), and my next step would indeed have been to implement my own
Action class with, e.g., a method events().

The very same structure, as far as I can deduce from a glimpse on astxx,
is one of the main improvements in the class hierarchy (taken aside the
more robust reduction of threads), so this looks quite promising, and I
guess I prefer to live with my self-knitted solution as is, until you do
better. Anyway, I would like to contribute to the testing, if you are
interested and I find the time.

I share your opinion about the importance of a versatile and robust
low-level functionality, nevertheless I think there should be a medium
level module, too, which reflects the spectrum of Manager actions,
including also database functions. For example, I don't get what makes
mailbox_count or setvar, say, (and even originate) more low-level than
database access?

Matthew Nicholson wrote:
> Jan,
>
> I don't think using self.command directly is the correct way to 
> implement this feature.  Also I don't think automatically handling 
> events for the user is the right way to do it either.
>
> I think pyst should be fairly low level and only provide an convent 
> interface to AGI and the Manager.  Also on the flip side, pyst should 
> not be designed to prevent the user from building a layer of abstraction 
> on top of it either.
>
> Either way, pyst 0.3 will make it easier to do these things in a more 
> straightforward manner.  No ETA on that though, for an idea of what it 
> might look like, check out astxx (http://matt-land.com/astxx).
>
>   

Re: [Pyst-users] functions for database access

[Matthew N. <mni...@di...>]

Jan Müller wrote:
> Matt,
> 
> thanks for your feedback. Like I've said, just quick and dirty. At least
> to my knowledge (searching the web for a day), so far, there are close
> to zero examples for the usage of pyst, so I meant to contribute a
> "how-to find back an event associated to an action" (identified by an
> action_id), and my next step would indeed have been to implement my own
> Action class with, e.g., a method events().
> 
> The very same structure, as far as I can deduce from a glimpse on astxx,
> is one of the main improvements in the class hierarchy (taken aside the
> more robust reduction of threads), so this looks quite promising, and I
> guess I prefer to live with my self-knitted solution as is, until you do
> better. Anyway, I would like to contribute to the testing, if you are
> interested and I find the time.

Ok, keep an eye on the mailing list for information on pyst 0.3, I can 
tell you now that there are no immediate plans to develop it, but I will 
work on it when I have some time and/or I have a pressing need for it.

> I share your opinion about the importance of a versatile and robust
> low-level functionality, nevertheless I think there should be a medium
> level module, too, which reflects the spectrum of Manager actions,
> including also database functions. For example, I don't get what makes
> mailbox_count or setvar, say, (and even originate) more low-level than
> database access?

Glad to see you understand my point of view.  I agree that there is a 
place for higher level functionality, but I don't think that should be 
included in the core functionality.  Maybe there should be a pyst-aux 
lib or something.

As far as mailbox_count and setvar, these manager actions are not 
defined in manager.c of the asterisk source, they are added by 
app_voicemail and db.c respectively.  This is perhaps why they are not 
included (I didn't write the first version of pyst, but that is why they 
are not in astxx::manager).  I am not completely opposed to having those 
commands included in the command set, although with pyst 0.3 it will be 
simple for users of the library to include custom actions (including 
your previous event handling action).

-- 
Matthew Nicholson
Digium