[OpenSIPS-Users] Sqlops in opensips ?

[Bogdan-Andrei Iancu]

Hi Alex,

When comes to none-SIP related stuff, there is a logical limit of what 
should be in or not - after all we do a SIP server and not a DB wrapper, 
neither a XMLRPC server, not an advanced language interpreter (and so one).

To give you an example of how I see this delimitation of what should be 
in OpenSIPS and what not. Let's take the DB case (anyhow the discussion 
started from there): the current DB support in script is a very decent 
one (via the avpsops functions) - you can do mostly all types of queries 
and DB interaction. If you need something more complex (from DB), I 
think you must work on the DB side and do the enhancements there. Make 
no sense to invest effort in doing super DB stuff in a SIP server, when 
the DB engine itself may already offer this support.

Again, an example - couple of weeks ago I had to interface OpenSIPS with 
some really complex data structures in a postgres DB - the solution was 
simple - some postgres procedures were created to hide the DB complexity 
and also to incorporate some logic. Form OpenSIPS point of view, the 
problem was reduced to running a select over the procedures.

So, the effort is better focused on SIP part rather is peripheral 
interaction, where we can use the already existing and specific tools 
and mechanism.

About the place of the DB related stuff - well, originally they were 
operating only with AVP and this is why they were put in the avpops. 
Now, indeed, there is no dependency for this, but the questions is what 
will be the advantage for a  users of moving  some functionality in a 
separate module ? I fail to see any...

Keeping the things simple is the best way to go IMO,

Regards,
Bogdan

Alex Balashov wrote:
> Brett Nemeroff wrote:
>
>   
>> The original intent was to be a fast, scalable SIP router. Having 
>> runtime queries against your database didn't fit into that model. Not 
>> only that there were no variables. So there was no way to manipulate or 
>> otherwise really use the resultant data.
>>     
>
> Sure.  But there is a limit to what can be done to meet 
> application-specific needs within the box of the existing modules 
> provided.  Along with the UAS features that co-evolved onto the proxy 
> layer, the increasing generalisation of the pseudoprogrammatic route 
> script environment is a logical direction.
>
>   
>> I agree that this stuffed into the AVP module seems odd, but given the 
>> AVP module gives the scripting language it's variable capabilities, it 
>> makes sense. 
>>     
>
> I wouldn't dispute that;  on the one hand, it is an odd place to put the 
> database interaction functionality, but on the other hand, it is 
> probably the most conceptually self-evident place of the existing module 
> library.
>
> I think the ideal answer is C, though - none of the above, make a 
> special module for it.
>
>   
>> Before AVPs, you did routing based on module logic and there wasn't 
>> anyway to customize it without writing your own modules by hand. As much 
>> odd as the avpops module integrates arbitrary database interactions, I'm 
>> not sure how I'd change it rather than a typical kind of prepare / 
>> execute/ fetch kind of loop. But that isn't an efficient design for a 
>> real-time switch. I rather like how it is today.
>>     
>
> It does pose a formidable design challenge;  there's not a lot of 
> usefulness in "asynchronous" database calls because it's no good - the 
> response from the database is still needed to carry on processing a 
> request, and that can only happen if the process blocks on database 
> response.
>
> What I think is in dire need of more asynchronous-minded renovation is 
> the fact that database calls can block an entire worker process.  Since 
> there are no threads used (that is to say, POSIX threads), a spuriously 
> latent database operation will block a whole child process.  Child 
> processes handle many requests concurrently in a high-volume scenario. 
> So, that needs to change.
>
>