On 5/13/13 6:44 AM, Juha Heinanen wrote:
Peter Dunkley writes:
I suppose an alternative function that just needs ruid could be written - but it would be much less efficient as it would have to linearly search all records (unless an additional hash on ruid is added - and a DB index on it too).
thanks for the explanation. now that we have ruid, the rest of usrloc has not clearly kept up with it. a new hash on ruid should be added. usrloc table already has unique index on ruid, which means that in db only mode, it should be quite easy to make the query only based on ruid.
For db only the sql query can be done only on ruid (for update and delete), there is a parameter for that now.
The aor is needed for memory, because the records are indexed in order to be able to find on save() and lookup() where the aor is in the sip message. Adding a second hash table just to index on ruid will make things more complex from point of view of memory use and synchronization between the two hashes.
I said in another email that actually the aorhash is needed, but if aor is known, computing aorhash is trivial.
Cheers, Daniel