[sr-dev] git:master: modules/mtree: when loading data from db, load each tree separately

Daniel-Constantin Mierla miconda at gmail.com
Wed Oct 30 21:16:31 CET 2013


On 10/30/13 6:47 PM, Juha Heinanen wrote:
> Daniel-Constantin Mierla writes:
>
>>> in my tests, the change that i made has worked fine.  in which case
>>> would it fail?
>> if you define the trees with module parameters, then you have to use
>> different tables in database, one for each. Those tables don't need
>> tname column.
> i have not found such a constraint in the readme.  is my patch somehow
> conflicting the current readme?
>
>> If you just store all the trees in one table (which has tname column),
>> then don't define them in the config, just set the table where they are
>> stored. A reload command will reload all the trees in that table
> the trees may have different types.  how can you tell that without mtree
> parameter?
>
> after the patch, one db table can have many trees each defined
> separately by mtree parameter.
>
> does that break something in the readme?
I haven't checked for now, but it doesn't really matters - readme is 
written after the code, not the other way around. If there is a missing 
description in the readme, it will be fixed.

Your patch breaks existing functionality, so practically you cannot have 
mtree table, only mtrees. That's not good because for large number of 
records (e.g., millions), I don't want to store tree name for each 
record when I know is only one (and do WHERE comparison for each load).

Again, see utils/kamctl/mysql/mtree-create.sql - both tables are there 
from the beginning of the module.

It is no a problem to add a patch that will enhance for defining trees 
that load from a table that has tname, But should not break the other one.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Trainings - Berlin, Nov 25-28
   - more details about Kamailio trainings at http://www.asipto.com -




More information about the sr-dev mailing list