15 Apr
2017
15 Apr
'17
9:59 a.m.
On 15.04.17 08:55, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
OK, feel free to update now -- if
anyone else complains later, it will
be discussed and decided again.
Cheers,
Daniel
--
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - May 22-24 (USA) - www.asipto.com
Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com
As I said, I haven't added this table, nor
use it, my guess was that
this constraint is to avoid having same (did,name,value) more than
once.
I have used domain_attrs to store properties that are common to all
users of the domain, e.g., which lcr index (= set of pstn gws) they
use, but I could imagine also something with multiple values, such as
which geoip countries users of the domain can place calls.
It doesn't seem to be an index for the
purpose of searching. If it loads
by did, then an index on did would be recommended, however, if it loads
all records at once and just groups by did in kamailio memory, then such
index will be useful. Eventually an index on did+name would be useful
when updating the records in database.
reload_tables() loads all records in
domain_attrs table to memory and
then adds them to hash table. There is no option for db_only operation.
So I don't see a point for such a unique index and suggest that it is
changed to non-unique index on did and name only.