[Serusers] load_attrs off a different table?

[SIP]

Jiri Kuthan wrote:
>>> As AVPs are going out of style, is there, then a way to store attributes 
>>> in other locations and yet still use the basic functions with them?
>>>       
>
> Not sure what is meant by going out of style?
>
> Anyhow, for custom-set schemes db_ops seems a good candidate for me as
> it doesn't impact the codebase.
>
>   

By going out of style, I meant that somewhere (correct me if I'm wrong), 
I thought I read that AVPops was being phased out of existence. I 
haven't had a look at db_ops yet, but the idea of custom queries opens 
up a whole new realm of possibilities.


>>> Our current SER 0.9.6 setup uses several tables to store important 
>>> information compartmentalised accordingly -- call return information, 
>>> aliases, etc.
>>>       
>
> aliases are actually in a separate table, uri, and are not folded in 
> attribtues.
>   

Are they updatable on the fly? For instance, currently, if we have a 
user who buys the phone number +1 404 555 1212, we just add that alias 
to the dbaliases table pointing to his username (1234567).  In the 
ser.cfg, instead of doing a lookup(aliases), we do an 
alias_db_lookup("dbaliases"). It looks it up from the table instead of 
the memory cache, and points things to the right place. If the alias 
changes, there's no restarting SER required to update the information, 
and there's no need to use xmlrpc or command line tools in order to make 
changes. We can just make changes to the DB within our web app code the 
same way we change all the other db data. It's clean and simple.

If I make changes to the new uri table to modify aliases, will they be 
available? Or do I have to use some sort of trick to get them into a mem 
cache in order for them to be usable (I haven't looked too closely at it 
yet personally, so I don't know)?

That's basically the functionality we're trying to ensure exists.

>   
>>> As we migrate from one server to another (an ongoing, but slow process 
>>> for us), we're still trying to ensure no functionality is lost. We don't 
>>> use xml-rpc calls. We don't use the old command-line serctl calls. We 
>>> don't want to. We use straight db access from the web services for any 
>>> and all functions to change settings -- easier to manage the codebase 
>>> for. 
>>>       
>
> Just curious -- how do you deal with cached data such as domain table?
> (FYI: our "trick" is in ser-oob.cfg)
>   

Not sure what you mean by this. There's currently (in our SER), no DNS 
data. All data in the location table is by IP. I think I'm not fully 
understanding the question... :-\

N.