21 Dec
2009
21 Dec
'09
10:50 p.m.
On 12/21/2009 03:42 PM, Henning Westerholt wrote:
On Mon, December 21, 2009 9:27 pm, Alex Balashov
wrote:
Indeed.
Having said that, AVPs are still very useful and necessary because they
persist across the lifetime of a transaction, so you can access them in
subsequent reply and failure routes. This is not true of user
pseudovariables ($var(...)), nor, as far as I know, of any other class
of pseudovariable at this point except special transaction-persistent
ones exported by modules.
As a result, it is often necessary for me to take data from $dbr
(sqlops) and load it into arrays of AVPs, such as for example when doing
custom fail-over in failure_route that uses logic for which dispatcher
is not suitable. I store a set of gateways in an AVP array along with
another AVP value indicating the current array index and iterate over
them in failure_route, and so on.
Daniel taught me how to use AVP arrays once, although I noticed this is
not mentioned anywhere in the avpops documentation. It should be
published somewhere, as it is one of the most useful programmatic
features of Kamailio.
Henning/Daniel, does Kamailio 3/SR offer any kind of better substitute
for what I am doing with AVPs as described above? In other words, are
there any transaction-persistent pseudovariables and/or namespace
containers that are easier to deal with syntactically, and provide more
advanced data structure primitives like arrays? I am aware of htable,
but I need something local to a transaction, not global.
--
Alex Balashov - Principal
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
[..]
In short, I don't think sqlops is materially faster, but it is a more
modern and sophisticated way to talk to your database and you should use
it for that reason.
Hey Alex,
as AVPs are also more or less just a special kind of pseudo-variable, like
the exported interface from the sqlops module there should be indeed no
notable speed difference, especially on today fast systems. But indeed
sqlops have the more appropriate interface and I would recommend it for
new deployments, for the reasons you summarized.