2 Nov
2013
2 Nov
'13
9:42 a.m.
mtree module still has a few issues:
- parameters mt_allow_duplicates/mt_ignore_duplicates seem to have global
meaning affecting all mtrees.
- if db_table module param is used instead of mtree module params, all
trees in the table must have either int or string values
my suggestion is that in the future db_table module param is removed and
all relevant other module parameters is moved to parameters of mtree
module parameter.
-- juha
2 Nov
2 Nov
8:51 p.m.
On 11/2/13 8:42 AM, Juha Heinanen wrote:
mtree module still has a few issues:
- parameters mt_allow_duplicates/mt_ignore_duplicates seem to have global
meaning affecting all mtrees.
Yes, module parameters are per module feature
control.
- if db_table module param is used instead of mtree module params, all
trees in the table must have either int or string values
Again, these are module
level values.
my suggestion is that in the future db_table module param is removed and
all relevant other module parameters is moved to parameters of mtree
module parameter.
This will not allow to have trees with dynamic name. Although I
am using
mainly config mtree-based definitions, the mechanism with db_table I
needed when I had to do prefix routing per user. So as soon as a
subscriber was added, a new tree was pushed in mtrees table and reloaded.
For the next major release development (4.2), we can analyze and some of
these module parameters can be stored in mtrees db table. But it is
question to add it for each record or add a new table to define trees...
there are good and parts with each approach.
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 -
4045
days inactive
4045
days old
1 comments
2 participants
participants (2)
-
Daniel-Constantin Mierla -
Juha Heinanen