25 Oct
2007
25 Oct
'07
1:05 a.m.
Jiri Kuthan wrote:
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.
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.
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.
> 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.
> 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.
> 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)