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