[sr-dev] Initial DB Merge Proposal

Jan Janak jan at ryngle.com
Fri Sep 25 13:10:59 CEST 2009


On Fri, Sep 25, 2009 at 1:04 PM, Jan Janak <jan at ryngle.com> wrote:
> On Fri, Sep 25, 2009 at 12:17 AM, Grzegorz Stanislawski
> <stangrze at netitel.pl> wrote:
>>> Maybe we could start by implementing the easier
>>> version, that would give us the possibility to configure the query
>>> string but not its parameters. That's trivial to implement. Later we
>>> could add support for arbitrary parameters that are resolved to AVPs,
>>> selects, PVs, whatever.
>>
>> Version capable of resolving variables would be very useful for accounting,
>> and this is actually already done for db_extra modparam.
>>
>> While having variable resolving for lookup queries might be overkill
>> especially that in some cases some PVs or AVPs are not yet known which may
>> lead to errors and confusion, i'd suggest not to trivialize it to syntax of
>> mysql_prepare. Having well defined %1 %2 or something like this, would allow
>> to for example use
>> "select .. from credentials where user=%1 and domain=%2" when multidomain
>> support is enabled and "select .. .. where user=%1" when not.
>> simple parser in module init could change % macros to ? and add certain keys
>> to list for further execution.
>
> That's not trivial to implement anymore, unlike my simplified proposal
> with '$' above. It's not only about the parser, you have to change the
> way how you pass parameters to the query in the module and that's the
> more complicated part. I am not saying that it is difficult to do, but
> it takes some planning and coding.
>
> And if we eventually do something like this, I'd prefer to do that one
> little extra step and implement support for selects, PVs, and AVPs
> instead of escape sequences like %1 and %2. The query from your
> example might then look like this:
>
> select ... where user=@authorization.username and domain=@from.uri.host
>
> Internally escape sequences like %1 and %2 would almost always be
> resolved to selects or PVs anyway simply because there are so many of
> them, they are convenient to use and they can extract almost anything
> from SIP messages or the proxy environment.

And I forgot to mention that patches are very much welcome, so if you
implement any of this, I'd be happy to include it.

  Thanks! Jan.



More information about the sr-dev mailing list