daniel,
i moved this to sr-dev list. when i read ht_db_load_table() code, i start to get impression that it assumes that the records are also ordered by key_name, which is not the case in the query.
-- juha
Hello,
On 5/24/11 9:40 PM, Juha Heinanen wrote:
daniel,
i moved this to sr-dev list. when i read ht_db_load_table() code, i start to get impression that it assumes that the records are also ordered by key_name, which is not the case in the query.
seems the db query result is ordered by key type instead of key name. Can you change that and test?
Thanks, Daniel
Daniel-Constantin Mierla writes:
seems the db query result is ordered by key type instead of key name. Can you change that and test?
daniel,
when i changed the ordering by key name:
db_key_t db_ord = &ht_db_name_column;
then sht_dump correctly showed 4 entries and ::size value was 4 too.
hope that that didn't break something else. if not, i would like this change to be committed to 3.1 and master.
-- juha
On 5/24/11 9:53 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
seems the db query result is ordered by key type instead of key name. Can you change that and test?
daniel,
when i changed the ordering by key name:
db_key_t db_ord =&ht_db_name_column;
then sht_dump correctly showed 4 entries and ::size value was 4 too.
hope that that didn't break something else. if not, i would like this change to be committed to 3.1 and master.
if you have only one array in the hash table, it should be fine. For more than one it may need a bit more tuning, as I could spot quickly right now.
Please wait a bit and I will analyze it deeper, probably tomorrow with fresh mind.
Thanks, Daniel
On 5/24/11 10:07 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
Please wait a bit and I will analyze it deeper, probably tomorrow with fresh mind.
yes, fine with me. perhaps you will find tomorrow a good solution.
I just committed a patch. Please give it a try, I couldn't test it for the moment.
The idea is to return the db records ordered by key and when there is a change of name, if the previous was supposed to be array, then add the size. Also, the keys for arrays are added with index.
If it works as expected, feel free to backport.
Thanks, Daniel
Daniel-Constantin Mierla writes:
The idea is to return the db records ordered by key and when there is a change of name, if the previous was supposed to be array, then add the size. Also, the keys for arrays are added with index.
If it works as expected, feel free to backport.
daniel,
now all four example entries get loaded, but size is one too large:
lpi::20033::prefix[2]:: +3587685601 lpi::20033::prefix[3]:: +3587645294 lpi::20033::prefix[0]:: +3587413481 lpi::20033::prefix[1]:: +35876801039 lpi::20033::prefix::size:: 5
same in some other cases that i checked.
-- juha
On 5/26/11 6:20 AM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
The idea is to return the db records ordered by key and when there is a change of name, if the previous was supposed to be array, then add the size. Also, the keys for arrays are added with index.
If it works as expected, feel free to backport.
daniel,
now all four example entries get loaded, but size is one too large:
lpi::20033::prefix[2]:: +3587685601 lpi::20033::prefix[3]:: +3587645294 lpi::20033::prefix[0]:: +3587413481 lpi::20033::prefix[1]:: +35876801039 lpi::20033::prefix::size:: 5
same in some other cases that i checked.
Can you try again? I just committed a patch, it was 1 too much indeed.
Cheers, Daniel
Daniel-Constantin Mierla writes:
Can you try again? I just committed a patch, it was 1 too much indeed.
daniel,
i tried again and now ::size is now correct. however, i'm still wondering this:
sip-proxy_ctl mi sht_dump htable | egrep '::flags' | wc 135 270 3138
mysql> select count(id) from htable where key_name like '%::flags'; +-----------+ | count(id) | +-----------+ | 136 | +-----------+
that is, i have other entries where key_name terminates with chars '::flags'. why mysql finds one more of those records than what sht_dump produces?
-- juha
Juha Heinanen writes:
that is, i have other entries where key_name terminates with chars '::flags'. why mysql finds one more of those records than what sht_dump produces?
this was ok. same key_name was twice in db. it would now be ok to cherry-pick the two commits to 3.1.
-- juha
On 5/24/11 9:50 PM, Daniel-Constantin Mierla wrote:
Hello,
On 5/24/11 9:40 PM, Juha Heinanen wrote:
daniel,
i moved this to sr-dev list. when i read ht_db_load_table() code, i start to get impression that it assumes that the records are also ordered by key_name, which is not the case in the query.
seems the db query result is ordered by key type instead of key name. Can you change that and test?
actually it should be key_type and key_name ... but that is limited by db api. Needs a bit more cooking...
Daniel
-
Daniel-Constantin Mierla -
Juha Heinanen