Hello,
from the last IRC devel meetings discussions, one topic was about adding
an unique id field per user profiles, with the decision to bring it to
mailing lists for broader audience.
That will help to reference easier across records. At this moment, the
most relationships are via (username) or (username,domain) when
use_domain=1, bringing some complexity.
The main reasons I came up to this were:
- in the perspective of gruu implementation for usrloc, with global
addresses, an unique (opaque) id seem to simplify things, no matter SIP
address of the user changes or not -- the public gruu id can be
different than the internal one, though
- it will open a new group of K and S modules for merging, S using
unique ids mostly everywhere
Moving towards it will be done gradually, keeping backward compatibility
for a while. The first steps will be to add new column in few tables
(subscriber, location), the username/domain columns will stay there
forever in most of the cases, they will become additional info over the
time (e.g., primary sip address in subscriber).
From the point of view of filling up the column, can be as simple as
setting it to username@domain, or generate some unique string with tools
out there.
Overall, there will be a bit more db space used at the benefit of
reduced complexity in the code. Jason Penton mentioned that IMS
architecture relies also on unique ids.
Looking forward to comments, alternatives, etc ... sr-users community
was cc-ed because it is not strictly technical discussion/decision.
Cheers,
Daniel
--
Daniel-Constantin Mierla
Kamailio Advanced Training, April 23-26, 2012, Berlin, Germany
http://www.asipto.com/index.php/kamailio-advanced-training/
Module: sip-router
Branch: master
Commit: 51f3e6d5ce60f32cf9af19511663bc2f5fdfedae
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=51f3e6d…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: Tue Mar 13 14:11:11 2012 +0100
p_usrloc: updated usage of DB replace method
- it has to be reviewed and fixed to make it work properly with db postgres
- no effects when using it like so far with mysql or unixodbc - it keeps
working like it was till now
---
modules_k/p_usrloc/ul_db_form_query.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/modules_k/p_usrloc/ul_db_form_query.c b/modules_k/p_usrloc/ul_db_form_query.c
index 258d53a..c89af2d 100644
--- a/modules_k/p_usrloc/ul_db_form_query.c
+++ b/modules_k/p_usrloc/ul_db_form_query.c
@@ -115,7 +115,7 @@ static int db_do_query(ul_db_op_t ul_op, db_func_t * dbf, db1_con_t * dbh, str *
}
return 0;
case UL_DB_REPL:
- if(dbf->replace(dbh, _k, _v, _n) < 0) {
+ if(dbf->replace(dbh, _k, _v, _n, 0, 0) < 0) {
LM_ERR("error in replacing in "
"table %.*s.\n", table->len, table->s);
return -1;
Module: sip-router
Branch: master
Commit: 061453b77e82e2fa92af2f57db67b6f9f8ac8302
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=061453b…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: Tue Mar 13 13:58:27 2012 +0100
lib/srdb1: updated DB API prototype for replace
- replace method takes two more parameters to allow implementation of
replace functionality inside the db connector module, via update,
affected rows and insert
- first is the number of column-value pairs to be used as unique key.
They have to be located at the beginning of the array given so far as
parameter to replace
- second is a mode, that will allow doing custom replace by:
- update, if affected rows == 0 then insert
- insert, if duplicate key error, then update
- for the db connectors that have access to a native REPLACE command in
the DB backend, the new parameters are ignored
---
lib/srdb1/db.h | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/lib/srdb1/db.h b/lib/srdb1/db.h
index e27969f..6d3a45d 100644
--- a/lib/srdb1/db.h
+++ b/lib/srdb1/db.h
@@ -245,10 +245,15 @@ typedef int (*db_update_f) (const db1_con_t* _h, const db_key_t* _k, const db_op
* \param _k key names
* \param _v values of the keys
* \param _n number of key=value pairs
+ * \param _un number of keys to build the unique key, starting from first _k
+ * \param _m mode - first update, then insert, or first insert, then update
+ * \note the last two parameters are used only if the DB server does not
+ * have native replace command (like postgres - the module doing an internal
+ * implementation using synchronized update/affected rows/insert mechanism)
* \return returns 0 if everything is OK, otherwise returns value < 0
*/
typedef int (*db_replace_f) (const db1_con_t* handle, const db_key_t* keys,
- const db_val_t* vals, const int n);
+ const db_val_t* vals, const int n, const int _un, const int _m);
/**