i was searching for a module that could be used to implement lookup of a string value based on two other strings.
matrix module would otherwise be ok, but i would need to have at least two matrixes. so a matrix_name column would need to be added to matrix table and matrix name argument to matrix function. also, i'm worried about the linked list implementation and would prefer a hash table based one: first look for the first index from a hash table, which would then point to the hash table of the second index.
use of dialplan module is another alternative. it would require giving a numerical index to each first string value, which could then be used as dpid. second string values would then be stored in match_exp column in rows of that that dpid and the value would in attrs column.
third alternative is htable module, i.e., use table_name::first_string::second_string as keyname and put string value in key_value column. in fact, that sounds like the best fit for the problem.
i would be interested to learn, why matrix module was developed in the first place. why is is better suited for the job than htable module? and if there are good reasons, why matrix module is better for its intended job than htable module, is there interest in developing matrix module further along the lines i described in above?
-- juha
On Monday 11 October 2010, Juha Heinanen wrote:
i was searching for a module that could be used to implement lookup of a string value based on two other strings.
Hello Juha,
at the moment this module supports only integer lookups, i think.
matrix module would otherwise be ok, but i would need to have at least two matrixes. so a matrix_name column would need to be added to matrix table and matrix name argument to matrix function. also, i'm worried about the linked list implementation and would prefer a hash table based one: first look for the first index from a hash table, which would then point to the hash table of the second index.
You need two isolated matrixes, i see. You're right, the moment the module only supports one table. Maybe i understood you wrong, but have you thought about storing the data of both in one table?
[..] i would be interested to learn, why matrix module was developed in the first place. why is is better suited for the job than htable module? and if there are good reasons, why matrix module is better for its intended job than htable module, is there interest in developing matrix module further along the lines i described in above?
One reason for developing the module was that there were no dialplan and htable available during the time we developed it. :-) Another reason is that its in this form conceptionally easier to understand, maintain and use for the (limited) requirements we've had for it so far. This was also the reason for the choice of a O(n) function for the lookup.
I'd say that changing the implementation of the lookup function should be not that complicated. Marius B., do you worked on it the last time, what do you think about it?
Regards,
Henning
Henning Westerholt writes:
One reason for developing the module was that there were no dialplan and htable available during the time we developed it. :-) Another reason is that its in this form conceptionally easier to understand, maintain and use for the (limited) requirements we've had for it so far. This was also the reason for the choice of a O(n) function for the lookup.
ok, but when you introduced matrix module to sr, htable module was already there and it looks to me that matrix module provides a subset of htable's functionality and implements that subset in a slower way.
in general, i don't think that it is a good idea to add modules that do not provide any new functionality or better performance as compared to existing modules. what is sr policy on this or is there any?
-- juha
On Monday 11 October 2010, Juha Heinanen wrote:
One reason for developing the module was that there were no dialplan and htable available during the time we developed it. :-) Another reason is that its in this form conceptionally easier to understand, maintain and use for the (limited) requirements we've had for it so far. This was also the reason for the choice of a O(n) function for the lookup.
ok, but when you introduced matrix module to sr, htable module was already there and it looks to me that matrix module provides a subset of htable's functionality and implements that subset in a slower way.
in general, i don't think that it is a good idea to add modules that do not provide any new functionality or better performance as compared to existing modules. what is sr policy on this or is there any?
Hello Juha,
well, in general i agree to you. We discussed this before with Daniel some time ago. So far he had no objections against it that time. It should be stable, in an internal version its in production use since years and its maintained by us. If somebody don't need the features that htable provides and its looking for something more simple (like just an array), then maybe he find the module as useful as we do.
In other areas we also have overlapping functionalies with different datastructures, like in RURI prefix rewriting: dispatcher (linked list), lcr (hash table), cr (trie), mtree (tree?) and also drouting (trie), which was added not that long ago.
Cheers,
Henning
Henning Westerholt writes:
In other areas we also have overlapping functionalies with different datastructures, like in RURI prefix rewriting: dispatcher (linked list), lcr (hash table), cr (trie), mtree (tree?) and also drouting (trie), which was added not that long ago.
sure there are overlaps, but before matrix module, there was no other module that was functionally a pure subset of an existing module and that was worse in performance.
-- juha
I'd say that changing the implementation of the lookup function should be not that complicated. Marius B., do you worked on it the last time, what do you think about it?
Hi,
I think given Juha's usecase, using the htable module is probably best. You could use one htable and the two strings concatenated separated by a unused character as key. This way you will have fast O(1) lookups and you can also use strings as keys.
As Henning said, the matrix module currently only supports integer lookups, and it is used as a generic matrix container. What we could really do is change the matrix module to act as a real matrix and have O(1) lookups. The current implementation is more as an array of lists then a matrix. This way, the module could be really useful if one needs just a generic, really fast matrix lookup container. I could work on changing the lookup functionality of the module, this shouldn't be so hard to do.
Regards,
Marius
-
Henning Westerholt -
Juha Heinanen -
Marius Bucur