30 Oct
2013
30 Oct
'13
10:16 p.m.
On 10/30/13 6:47 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
i have not found such a constraint in the readme. is my patch
somehow
conflicting the current 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 -
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. 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?