I'm looking through the SER 2.0 documentation, and I'm trying to find out more information about load_attrs. Currently, I can't look at the module search thing, so I'm not sure where this function comes from, and there's no documentation about it. I know what it DOES.... but I'm trying to find out if there's a way to use it to load attributes from tables other than the usr_attrs table.
We like to have compartmentalised tables that are more logical in their outlay, so we'd like to keep some attributes elsewhere. We're also concerned that, with a LARGE number of users each with a LARGE number of attributes and aliases and subattributes, etc, the performance will degrade (MySQL doesn't do as well with enormous tables as it does with smaller tables of data).
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?
Our current SER 0.9.6 setup uses several tables to store important information compartmentalised accordingly -- call return information, aliases, etc.
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. With this in mind, everything we do is focused on a migration that allows us to keep a logical relational database structure that is accessed through native calls.
Just a very quick answer before I get you a better one ... with db_ops one can do pretty much anything -- formulate a query and process it as AVPs in SER script.
-jiri
At 15:28 18/10/2007, SIP wrote:
I'm looking through the SER 2.0 documentation, and I'm trying to find out more information about load_attrs. Currently, I can't look at the module search thing, so I'm not sure where this function comes from, and there's no documentation about it. I know what it DOES.... but I'm trying to find out if there's a way to use it to load attributes from tables other than the usr_attrs table.
We like to have compartmentalised tables that are more logical in their outlay, so we'd like to keep some attributes elsewhere. We're also concerned that, with a LARGE number of users each with a LARGE number of attributes and aliases and subattributes, etc, the performance will degrade (MySQL doesn't do as well with enormous tables as it does with smaller tables of data).
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?
Our current SER 0.9.6 setup uses several tables to store important information compartmentalised accordingly -- call return information, aliases, etc.
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. With this in mind, everything we do is focused on a migration that allows us to keep a logical relational database structure that is accessed through native calls.
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
Yes, there is extra_attrs extension in the avp_db module.
Check modules/avp_db/doc/avp_dialogs.cfg which shows complex job done using this feature.
Michal
On Thu, 2007-10-18 at 09:28 -0400, SIP wrote:
I'm looking through the SER 2.0 documentation, and I'm trying to find out more information about load_attrs. Currently, I can't look at the module search thing, so I'm not sure where this function comes from, and there's no documentation about it. I know what it DOES.... but I'm trying to find out if there's a way to use it to load attributes from tables other than the usr_attrs table.
We like to have compartmentalised tables that are more logical in their outlay, so we'd like to keep some attributes elsewhere. We're also concerned that, with a LARGE number of users each with a LARGE number of attributes and aliases and subattributes, etc, the performance will degrade (MySQL doesn't do as well with enormous tables as it does with smaller tables of data).
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?
Our current SER 0.9.6 setup uses several tables to store important information compartmentalised accordingly -- call return information, aliases, etc.
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. With this in mind, everything we do is focused on a migration that allows us to keep a logical relational database structure that is accessed through native calls.
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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)
-jiri
-- Jiri Kuthan http://iptel.org/~jiri/
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.
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/
-
Jiri Kuthan -
Michal Matyska -
SIP