Re: [asterisk-dev] AstDB mySQL implementation

2017-10-31 Thread Nir Simionovich
Yes, that's not a bad start - but I believe that are dozens other functions that should be used - instead of other functions. For example, I remember that a while back atoi and itoa were said to be unsafe and that there is a better "asteriskian" way of using those. For example, the Wiki says:

Re: [asterisk-dev] AstDB mySQL implementation

2017-10-30 Thread Kevin Harwell
On Mon, Oct 30, 2017 at 1:19 PM, Nir Simionovich wrote: > Definite +1 on the Documentation side - for sure. Here is a stupid > question, is there a "Best Practices" coding document somewhere? > I remember that many years ago there was something really basic, but much >

Re: [asterisk-dev] AstDB mySQL implementation

2017-10-30 Thread Nir Simionovich
Definite +1 on the Documentation side - for sure. Here is a stupid question, is there a "Best Practices" coding document somewhere? I remember that many years ago there was something really basic, but much has changed since then. On Mon, Oct 30, 2017 at 6:53 PM Corey Farrell

Re: [asterisk-dev] AstDB mySQL implementation

2017-10-30 Thread Corey Farrell
I think astdb itself is an inappropriate place to deal with this.  astdb is initialized well before module preloads so it would be nearly impossible for modules to provide the astdb implementation.  In my opinion astdb is a database "implementation", not a connector (and that shouldn't

Re: [asterisk-dev] AstDB mySQL implementation

2017-10-29 Thread Nir Simionovich
Seems like I have under estimated the task at hand, as this part of Asterisk requires some more intricate familiarity with how AstDB truly works. It would be one thing to "change the backend" it would a far more complex task to "make two backends selectable". Conclusion - not sure this is worth

Re: [asterisk-dev] AstDB mySQL implementation

2017-10-26 Thread Nir Simionovich
Correction, seems like this requires a bit more architecture than I anticipated. Basically, we need to separate this into several files and turn the entire AstDB concept into a pluggable module type module. But, as AstDB is a mandatory module for Asterisk, can we create a situation where a

Re: [asterisk-dev] AstDB mySQL implementation

2017-10-26 Thread Nir Simionovich
I'll have a look at it. If I read the code correctly, the AstDB is invoked from the asterisk.c file, when asterisk is launched. I think the best would be to add a configuration file like astdb.conf, which will look something like this: [general] engine=builtin ; values can be either builtin,

Re: [asterisk-dev] AstDB mySQL implementation

2017-10-26 Thread Olle E. Johansson
> On 26 Oct 2017, at 15:25, Nir Simionovich wrote: > > I suspect the original code didn't change the overall mechanism dramatically, > it's mainly a new implementation. > This thing is this - replacing the implementation seems straight forward > enough, making it

Re: [asterisk-dev] AstDB mySQL implementation

2017-10-26 Thread Nir Simionovich
I suspect the original code didn't change the overall mechanism dramatically, it's mainly a new implementation. This thing is this - replacing the implementation seems straight forward enough, making it configurable, seems like a pain in the butt. On Thu, Oct 26, 2017 at 4:23 PM Olle E.

Re: [asterisk-dev] AstDB mySQL implementation

2017-10-26 Thread Olle E. Johansson
> On 26 Oct 2017, at 15:20, Nir Simionovich wrote: > > Just looked into the code, this is not a simple task to put a new backend for > astdb. The code isn't even designed > for something like that. Judging from what I can tell, and tell me if I'm > wrong - turning

Re: [asterisk-dev] AstDB mySQL implementation

2017-10-26 Thread Nir Simionovich
Just looked into the code, this is not a simple task to put a new backend for astdb. The code isn't even designed for something like that. Judging from what I can tell, and tell me if I'm wrong - turning this into a configurable thing would be more or less an open-heart surgery. On Thu, Oct 26,

Re: [asterisk-dev] AstDB mySQL implementation

2017-10-26 Thread Olle E. Johansson
Somewhere in Asterisk space, there’s an old patch where I added ASTDB over realtime, meaning you can use any realtime storage. If I remember correctly there was a bit of chicken-and-egg problem with some astdb calls happening before realtime got launched, but otherwise it worked just fine in

Re: [asterisk-dev] AstDB mySQL implementation

2017-10-26 Thread Nir Simionovich
I'd like to +1 on that idea. While I'm somewhat reluctant to using mySQL as the base of such a change, as mySQL is an overkill for AstDB, having a proper AstDB configurable backend is an interesting thing. Personally speaking, I would actually prefer something like Memcache or preferably Redis.

Re: [asterisk-dev] AstDB mySQL implementation

2017-09-25 Thread Matt Fredrickson
On Fri, Sep 22, 2017 at 12:12 PM, Ryan Wagoner wrote: > I've been scaling out FreePBX horizontally with Kamailio and custom > FreePBX modules mainly to handle call center outbound dialing (around 20k > calls per day). One of the issues I ran into was FreePBX uses the AstDB >

Re: [asterisk-dev] AstDB mySQL implementation

2017-09-22 Thread Joshua Colp
On Fri, Sep 22, 2017, at 02:12 PM, Ryan Wagoner wrote: > I've been scaling out FreePBX horizontally with Kamailio and custom > FreePBX > modules mainly to handle call center outbound dialing (around 20k calls > per > day). One of the issues I ran into was FreePBX uses the AstDB extensively > and

[asterisk-dev] AstDB mySQL implementation

2017-09-22 Thread Ryan Wagoner
I've been scaling out FreePBX horizontally with Kamailio and custom FreePBX modules mainly to handle call center outbound dialing (around 20k calls per day). One of the issues I ran into was FreePBX uses the AstDB extensively and will write changes to it from the dialplan or the FreePBX user