[Serusers] load_attrs off a different table?

[Jiri Kuthan]

At 03:05 25/10/2007, SIP wrote:
>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. 

not really. You may be possible referring to replacement of all the AVP manipulation functions
with select operators. AVPs for sure stay, as they are heart of user-driven services.

>I haven't had a look at db_ops yet, but the idea of custom queries opens up a whole new realm of possibilities.

yeah.



>>>>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? 

yes

>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.

The aliases are not cached. The URI table has as many aliases as you wish, all of them pointing to
a unique identifier.

You may find the DB relationship diagram useful:http://www.iptel.org/files/db-structure-0.10.pdf


>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... :-\

I see -- I guess you are running single-domain operation and the domain name is hardwired
in the script. If you had multiple domains, you would have to worry about their names 
in cache....

-jiri


>N.



--
Jiri Kuthan            http://iptel.org/~jiri/