Module: sip-router Branch: andrei/dbk_lib Commit: 174881d2ffeb43a06566b57707a398ee8a1bcdf5 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=174881d2...
Author: Andrei Pelinescu-Onciul andrei@iptel.org Committer: Andrei Pelinescu-Onciul andrei@iptel.org Date: Fri Nov 21 03:31:32 2008 +0100
libsr_dbk: added kamailio db interface as lib
- kamailio db interface tranformed into library (Makefile added, include path changed)
---
lib/sr_dbk/Makefile | 14 ++++++++++++++ lib/sr_dbk/README | 14 +++++++++----- lib/sr_dbk/db.c | 8 ++++---- lib/sr_dbk/db_con.h | 2 +- lib/sr_dbk/db_id.c | 6 +++--- lib/sr_dbk/db_id.h | 2 +- lib/sr_dbk/db_key.h | 2 +- lib/sr_dbk/db_pool.c | 2 +- lib/sr_dbk/db_query.c | 2 +- lib/sr_dbk/db_res.c | 4 ++-- lib/sr_dbk/db_row.c | 4 ++-- lib/sr_dbk/db_ut.c | 4 ++-- lib/sr_dbk/db_val.h | 2 +- 13 files changed, 42 insertions(+), 24 deletions(-)
diff --git a/lib/sr_dbk/Makefile b/lib/sr_dbk/Makefile new file mode 100644 index 0000000..2c21b96 --- /dev/null +++ b/lib/sr_dbk/Makefile @@ -0,0 +1,14 @@ +# +# example library makefile +# + +include ../../Makefile.defs +auto_gen= +NAME:=sr_dbk +MAJOR_VER=1 +MINOR_VER=0 +BUGFIX_VER=0 +LIBS= + +include ../../Makefile.libs + diff --git a/lib/sr_dbk/README b/lib/sr_dbk/README index bbdc03e..cd4fb44 100644 --- a/lib/sr_dbk/README +++ b/lib/sr_dbk/README @@ -1,7 +1,11 @@ $Id$
-This directory contains generic database support interface. The interface -should be used by all modules willing to communicate with a database. Kamailio -can then switch from one database to another simply by loading a different -database support module. Directory example contains a very simple example -how to use the interface. Directory doc contains the API documentation. +This directory contains the Kamailio generic database support library. +The library should be used by all modules willing to communicate with a +database. Kamailio can then switch from one database to another simply by +loading a different database support module. Directory example contains a +very simple example how to use the interface. Directory doc contains the API +documentation. + +Note that you can use sip-router with 2 different database interfaces: + ser and kamailio. diff --git a/lib/sr_dbk/db.c b/lib/sr_dbk/db.c index f24646a..772bb12 100644 --- a/lib/sr_dbk/db.c +++ b/lib/sr_dbk/db.c @@ -57,10 +57,10 @@ * - \ref db_unixodbc */
-#include "../dprint.h" -#include "../sr_module.h" -#include "../mem/mem.h" -#include "../ut.h" +#include "../../dprint.h" +#include "../../sr_module.h" +#include "../../mem/mem.h" +#include "../../ut.h" #include "db_cap.h" #include "db_id.h" #include "db_pool.h" diff --git a/lib/sr_dbk/db_con.h b/lib/sr_dbk/db_con.h index 08aa0f1..7804f07 100644 --- a/lib/sr_dbk/db_con.h +++ b/lib/sr_dbk/db_con.h @@ -30,7 +30,7 @@ #ifndef DB_CON_H #define DB_CON_H
-#include "../str.h" +#include "../../str.h"
/*! \brief diff --git a/lib/sr_dbk/db_id.c b/lib/sr_dbk/db_id.c index ad23881..3be3307 100644 --- a/lib/sr_dbk/db_id.c +++ b/lib/sr_dbk/db_id.c @@ -28,9 +28,9 @@ */
#include "db_id.h" -#include "../dprint.h" -#include "../mem/mem.h" -#include "../ut.h" +#include "../../dprint.h" +#include "../../mem/mem.h" +#include "../../ut.h" #include <stdlib.h> #include <string.h>
diff --git a/lib/sr_dbk/db_id.h b/lib/sr_dbk/db_id.h index 2650e6e..641417d 100644 --- a/lib/sr_dbk/db_id.h +++ b/lib/sr_dbk/db_id.h @@ -30,7 +30,7 @@ #ifndef _DB_ID_H #define _DB_ID_H
-#include "../str.h" +#include "../../str.h"
/** Structure representing a database ID */ struct db_id { diff --git a/lib/sr_dbk/db_key.h b/lib/sr_dbk/db_key.h index a03795a..50fd8aa 100644 --- a/lib/sr_dbk/db_key.h +++ b/lib/sr_dbk/db_key.h @@ -30,7 +30,7 @@ #ifndef DB_KEY_H #define DB_KEY_H
-#include "../ut.h" +#include "../../ut.h"
/** diff --git a/lib/sr_dbk/db_pool.c b/lib/sr_dbk/db_pool.c index a87f7c4..6a1a9fc 100644 --- a/lib/sr_dbk/db_pool.c +++ b/lib/sr_dbk/db_pool.c @@ -27,7 +27,7 @@ * \ingroup db */
-#include "../dprint.h" +#include "../../dprint.h" #include "db_pool.h"
diff --git a/lib/sr_dbk/db_query.c b/lib/sr_dbk/db_query.c index eb7a798..609e935 100644 --- a/lib/sr_dbk/db_query.c +++ b/lib/sr_dbk/db_query.c @@ -33,7 +33,7 @@ */
#include <stdio.h> -#include "../dprint.h" +#include "../../dprint.h" #include "db_ut.h" #include "db_query.h"
diff --git a/lib/sr_dbk/db_res.c b/lib/sr_dbk/db_res.c index 27d162f..d82fae6 100644 --- a/lib/sr_dbk/db_res.c +++ b/lib/sr_dbk/db_res.c @@ -33,8 +33,8 @@ #include "db_res.h"
#include "db_row.h" -#include "../dprint.h" -#include "../mem/mem.h" +#include "../../dprint.h" +#include "../../mem/mem.h"
#include <string.h>
diff --git a/lib/sr_dbk/db_row.c b/lib/sr_dbk/db_row.c index 090adb7..e690d5b 100644 --- a/lib/sr_dbk/db_row.c +++ b/lib/sr_dbk/db_row.c @@ -33,8 +33,8 @@ #include "db_row.h"
#include <string.h> -#include "../dprint.h" -#include "../mem/mem.h" +#include "../../dprint.h" +#include "../../mem/mem.h"
/* * Release memory used by row diff --git a/lib/sr_dbk/db_ut.c b/lib/sr_dbk/db_ut.c index 2c86b17..cf7abf3 100644 --- a/lib/sr_dbk/db_ut.c +++ b/lib/sr_dbk/db_ut.c @@ -32,8 +32,8 @@
#include "db_ut.h"
-#include "../mem/mem.h" -#include "../dprint.h" +#include "../../mem/mem.h" +#include "../../dprint.h" #include <limits.h> #include </usr/include/limits.h> #include <errno.h> diff --git a/lib/sr_dbk/db_val.h b/lib/sr_dbk/db_val.h index ab9314b..fad0b24 100644 --- a/lib/sr_dbk/db_val.h +++ b/lib/sr_dbk/db_val.h @@ -37,7 +37,7 @@ #define DB_VAL_H
#include <time.h> -#include "../str.h" +#include "../../str.h"
/**
Note that lib/sr_dbk includes all the history from kamailio/openser (if you run git log on lib/sr_dbk you'll see all the commits from svn that touched db/).
I've also created a script that automatically converts a kamailio module to sip-router. It adds -DKAMAILIO_MOD_INTERFACE to the Makefile and if the module uses DB, it automatically fixes all the includes and adds the link with libsk_dbk makefile magic. (attached, it might make sense to have it on git, but I can't think of a good place for it)
I think we should merge everything into master, or some other branch, because there are too many branches at this point and it's hard to say which is the one most up-to-date. It will generate a lot of emails (all the commits merged will generate an email). We could also wait a little longer and try to come up with some commit email policy. We have 3 options: 1. like now, all commits to all branches are emailed, for every merge 2. we have "silent" branches (e.g. <username>/.*) with no emails, and normal branches (e.g. master) 3. all branches send emails, but a commit will be sent only once (you will not see the email again when somebody merges one branch that has it into a branch that doesn't have it).
Andrei
On 21-11 03:46, Andrei Pelinescu-Onciul wrote:
Note that lib/sr_dbk includes all the history from kamailio/openser (if you run git log on lib/sr_dbk you'll see all the commits from svn that touched db/).
I've also created a script that automatically converts a kamailio module to sip-router. It adds -DKAMAILIO_MOD_INTERFACE to the Makefile and if the module uses DB, it automatically fixes all the includes and adds the link with libsk_dbk makefile magic. (attached, it might make sense to have it on git, but I can't think of a good place for it)
I just commited the stuff that I created. Basically it is the same approach as yours, except that I went a bit further and added both db api versions as libraries.
Furthermore I took both ser and kamailio mysql modules and integrated them into a single db_mysql module which supports both versions of the db API and links with both libraries.
There were some conflicts in identifiers so I used the most straightforward approach and renamed the conflicting names in the older version, for example, db_con_t becomes db_con1_t there.
You can find it in branch janakj/db, I only took it to the state when it compiles, this stuff is not supposed to be used or merged into the master branch, I only commited it so that others (Henning) can take a look at it and comment.
The renaming of some data structures and typedefs only needs to be done in the libraries and in the database drivers that link with both libraries. In other modules we can just typedef them to the correct version depending on the version of the library the module is using, so there will be no need to change the code of all modules.
This approach is quite straightforward and we can make lots of modules from both projects work quickly with the integrated core. Eventually, after all modules are converted to the new db api, we can drop support for the older library and remove the old interface from database drivers.
Unless nobody objects, I would suggest we do the following:
1) Convert both API versions into libraries. Here I would suggest some simpler name, sr_dbk sounds is cryptic, how about using just db1 and db2 possibly prefixed with sr (libsrdb1, libsrdb2)?
2) Rename conflicting identifiers in both libraries, i.e. db_con1, db_con2, db_res1, db_res2.
2) Merge database drivers from both projects. Here I would suggest we adopt the naming scheme from Kamailio and prefix all of them with db_.
4) Link modules that use db with one of the libraries.
Jan.
On Nov 21, 2008 at 04:34, Jan Janak jan@iptel.org wrote: [...]
Unless nobody objects, I would suggest we do the following:
- Convert both API versions into libraries. Here I would suggest some simpler name, sr_dbk sounds is cryptic, how about using just db1 and db2
possibly prefixed with sr (libsrdb1, libsrdb2)?
Do we go for libsrdb[12] or somebody has a better ideea?
Do I keep the kamailio db history or we use directly Jan's version (no history)?
- Rename conflicting identifiers in both libraries, i.e. db_con1, db_con2, db_res1, db_res2.
I think we would have to rename the DB_* macros too: DB1_STR DB1_INT DB1_BLOB DB1_BIGINT DB1_DOUBLE DB1_STRING DB1_DATETIME DB1_BITMAP
From my point of view it's ok as long as we can write a script that
would convert a module automatically (and all these are just simple search & replace).
- Merge database drivers from both projects. Here I would suggest we adopt the naming scheme from Kamailio and prefix all of them with db_.
I agree.
- Link modules that use db with one of the libraries.
5) create scripts that would automatically update a kamailio or ser module for use with sip-router
Andrei
Andrei Pelinescu-Onciul wrote:
On Nov 21, 2008 at 04:34, Jan Janak jan@iptel.org wrote: [...]
Unless nobody objects, I would suggest we do the following:
- Convert both API versions into libraries. Here I would suggest some simpler name, sr_dbk sounds is cryptic, how about using just db1 and db2
possibly prefixed with sr (libsrdb1, libsrdb2)?Do we go for libsrdb[12] or somebody has a better ideea?
what about db (for ser's DB) and dbk for K's?
klaus
Do I keep the kamailio db history or we use directly Jan's version (no history)?
- Rename conflicting identifiers in both libraries, i.e. db_con1, db_con2, db_res1, db_res2.
I think we would have to rename the DB_* macros too: DB1_STR DB1_INT DB1_BLOB DB1_BIGINT DB1_DOUBLE DB1_STRING DB1_DATETIME DB1_BITMAP
From my point of view it's ok as long as we can write a script that would convert a module automatically (and all these are just simple search & replace).
- Merge database drivers from both projects. Here I would suggest we adopt the naming scheme from Kamailio and prefix all of them with db_.
I agree.
- Link modules that use db with one of the libraries.
- create scripts that would automatically update a kamailio or ser
module for use with sip-router
Andrei
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
On 11/21/08 21:14, Klaus Darilion wrote:
Andrei Pelinescu-Onciul wrote:
On Nov 21, 2008 at 04:34, Jan Janak jan@iptel.org wrote: [...]
Unless nobody objects, I would suggest we do the following:
- Convert both API versions into libraries. Here I would suggest some simpler name, sr_dbk sounds is cryptic, how about using just db1 and db2
possibly prefixed with sr (libsrdb1, libsrdb2)?Do we go for libsrdb[12] or somebody has a better ideea?
what about db (for ser's DB) and dbk for K's?
for me db[12] sounds better from versioning point of view, maybe in the future we will have a new one -- db3 -- hopefully not :-)
Cheers, Daniel
klaus
Do I keep the kamailio db history or we use directly Jan's version (no history)?
- Rename conflicting identifiers in both libraries, i.e. db_con1, db_con2, db_res1, db_res2.
I think we would have to rename the DB_* macros too: DB1_STR DB1_INT DB1_BLOB DB1_BIGINT DB1_DOUBLE DB1_STRING DB1_DATETIME DB1_BITMAP
From my point of view it's ok as long as we can write a script that would convert a module automatically (and all these are just simple search & replace).
- Merge database drivers from both projects. Here I would suggest we adopt the naming scheme from Kamailio and prefix all of them with db_.
I agree.
- Link modules that use db with one of the libraries.
- create scripts that would automatically update a kamailio or ser
module for use with sip-router
Andrei
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
On Friday 21 November 2008, Andrei Pelinescu-Onciul wrote:
On Nov 21, 2008 at 04:34, Jan Janak jan@iptel.org wrote: [...]
Unless nobody objects, I would suggest we do the following:
- Convert both API versions into libraries. Here I would suggest some simpler name, sr_dbk sounds is cryptic, how about using just db1 and
db2 possibly prefixed with sr (libsrdb1, libsrdb2)?
Do we go for libsrdb[12] or somebody has a better ideea?
Do I keep the kamailio db history or we use directly Jan's version (no history)?
Hi Andrei,
if you can keep the history this would be nice, but we can also use Jans version directly. For the naming, libsrdb1 and libsrdb2 is ok.
- Rename conflicting identifiers in both libraries, i.e. db_con1,
db_con2, db_res1, db_res2.
I think we would have to rename the DB_* macros too: DB1_STR DB1_INT DB1_BLOB DB1_BIGINT DB1_DOUBLE DB1_STRING DB1_DATETIME DB1_BITMAP
I agree that we need to rename the identifiers, but it is really necessary to rename the macros also? Do we plan to compile a module with both DB APIs at the same time?
Cheers,
Henning
On 24-11 10:52, Henning Westerholt wrote:
I think we would have to rename the DB_* macros too: DB1_STR DB1_INT DB1_BLOB DB1_BIGINT DB1_DOUBLE DB1_STRING DB1_DATETIME DB1_BITMAP
I agree that we need to rename the identifiers, but it is really necessary to rename the macros also? Do we plan to compile a module with both DB APIs at the same time?
The identifiers above are belong to an enum. We have to rename them if we want to include both versions of the API from a single module--and we need to do that in the database drivers--otherwise we would need to maintain to versions of every database driver.
Jan.
On Nov 24, 2008 at 10:52, Henning Westerholt henning.westerholt@1und1.de wrote:
On Friday 21 November 2008, Andrei Pelinescu-Onciul wrote:
On Nov 21, 2008 at 04:34, Jan Janak jan@iptel.org wrote: [...]
Unless nobody objects, I would suggest we do the following:
- Convert both API versions into libraries. Here I would suggest some simpler name, sr_dbk sounds is cryptic, how about using just db1 and
db2 possibly prefixed with sr (libsrdb1, libsrdb2)?
Do we go for libsrdb[12] or somebody has a better ideea?
Do I keep the kamailio db history or we use directly Jan's version (no history)?
Hi Andrei,
if you can keep the history this would be nice, but we can also use Jans version directly. For the naming, libsrdb1 and libsrdb2 is ok.
Yes we can. We just need to rename sr_dbk into srdb1 and then apply Jan changes on it. At some latter point I plan to try connecting db/libdb1 history with ser history (connect the first kamailio db commit to the last db commit in ser before the kamailo fork).
- Rename conflicting identifiers in both libraries, i.e. db_con1,
db_con2, db_res1, db_res2.
I think we would have to rename the DB_* macros too: DB1_STR DB1_INT DB1_BLOB DB1_BIGINT DB1_DOUBLE DB1_STRING DB1_DATETIME DB1_BITMAP
I agree that we need to rename the identifiers, but it is really necessary to rename the macros also? Do we plan to compile a module with both DB APIs at the same time?
Yes, for the database drivers (mysql, postgress a.s.o). I don't know for the others, it might make sense to do this for them too.
So far the conflicting macros/enums that I know about are (s means present only in ser 2.1+, k only in kamailio, ' ' common):
s DB_NONE DB_INT k DB_BIGINT s DB_DOUBLE s DB_CSTR k DB_STRING - smae thing as ser DB_CSTR DB_STR DB_DATETIME DB_BLOB DB_BITMAP
So we could also rearange the enums so that the common members have the same value. That would avoid renaming to DB1_xxx / DB2_xxx, but I'm not sure if this wouldn't be more confusing then renaming (which after all is a scriptable search & replace).
I personally don't have any preference (I'm usually not involved in db stuff anyway :-)).
I will merge all the "stable" changes to master (everything except the db stuff) later today.
Andrei
On 24-11 13:37, Andrei Pelinescu-Onciul wrote:
On Nov 24, 2008 at 10:52, Henning Westerholt henning.westerholt@1und1.de wrote: Yes, for the database drivers (mysql, postgress a.s.o). I don't know for the others, it might make sense to do this for them too.
So far the conflicting macros/enums that I know about are (s means present only in ser 2.1+, k only in kamailio, ' ' common):
s DB_NONE DB_INT k DB_BIGINT s DB_DOUBLE s DB_CSTR k DB_STRING - smae thing as ser DB_CSTR DB_STR DB_DATETIME DB_BLOB DB_BITMAP
So we could also rearange the enums so that the common members have the same value. That would avoid renaming to DB1_xxx / DB2_xxx, but I'm not sure if this wouldn't be more confusing then renaming (which after all is a scriptable search & replace).
That's how I started but realized that it is much easier just to rename all of them with a script. I would personally prefer to rename all enums from srdb1 to DB1_INT, DB1_BIGINT and so on, and keep the names from srdb2.
I personally don't have any preference (I'm usually not involved in db stuff anyway :-)).
I will merge all the "stable" changes to master (everything except the db stuff) later today.
OK, should I do the db stuff then or do you want to do it? I can take of merging it into the master once you merge other changes we will need to make that happen, such as all the module compatibility changes.
Most of us seem to agree on the following list of db changes:
* preserving history in libraries * naming the libraries as srdb1, srdb2 * renaming conflicting identifiers (db_con1, DB1_INT) * merged (with support for versions of the db api) database drivers * db_* naming convention for database drivers * a script to update modules in ser/kamailio repositories.
Jan.
On Monday 24 November 2008, Jan Janak wrote:
[..]
- merged (with support for versions of the db api) database drivers
Hi Jan,
merging both drivers into one has clearly some advantages. But from a compatibility and maintenance POV i'd think having both of them seperately would also make sense. It also would make it more easier to remove one of them after all modules get upgraded.
Another issue is the licence, this database drivers are GPL where we don't have the complete copyright from. Would not this create problems for you?
Cheers,
Henning
On Nov 24, 2008 at 13:52, Jan Janak jan@ryngle.com wrote:
[...]
OK, should I do the db stuff then or do you want to do it? I can take of merging it into the master once you merge other changes we will need to make that happen, such as all the module compatibility changes.
Yes, feel free to do it. I think you should either start a new branch from andrei/dbk_lib and add your changes on top of it or you could git cherry-pick commits 279ba2426ccf399d9f7c2054727868d4c1fc914f and perhaps 174881d2ffeb43a06566b57707a398ee8a1bcdf5. (BTW: Makefile.nonser is not needed, it's an unmaintained and most likely obsolete attempt to have the libraries compile outside of ser/sip-router (IIRC)).
[...]
Andrei
On Friday 21 November 2008, Jan Janak wrote:
On 21-11 03:46, Andrei Pelinescu-Onciul wrote:
Note that lib/sr_dbk includes all the history from kamailio/openser (if you run git log on lib/sr_dbk you'll see all the commits from svn that touched db/).
I've also created a script that automatically converts a kamailio module to sip-router. It adds -DKAMAILIO_MOD_INTERFACE to the Makefile and if the module uses DB, it automatically fixes all the includes and adds the link with libsk_dbk makefile magic. (attached, it might make sense to have it on git, but I can't think of a good place for it)
I just commited the stuff that I created. Basically it is the same approach as yours, except that I went a bit further and added both db api versions as libraries.
Furthermore I took both ser and kamailio mysql modules and integrated them into a single db_mysql module which supports both versions of the db API and links with both libraries. [..]
Hi Jan,
unfortunally i was not able to take a closer look to the stuff you commited, i'll try to comment later today. As already suggested i'd also think that we should perhaps try to reduce the number of branches, otherwise its hard to understand where the most up to date version is, what should be reviewed and tested..
Cheers,
Henning
On 24-11 11:04, Henning Westerholt wrote:
On Friday 21 November 2008, Jan Janak wrote:
On 21-11 03:46, Andrei Pelinescu-Onciul wrote:
Note that lib/sr_dbk includes all the history from kamailio/openser (if you run git log on lib/sr_dbk you'll see all the commits from svn that touched db/).
I've also created a script that automatically converts a kamailio module to sip-router. It adds -DKAMAILIO_MOD_INTERFACE to the Makefile and if the module uses DB, it automatically fixes all the includes and adds the link with libsk_dbk makefile magic. (attached, it might make sense to have it on git, but I can't think of a good place for it)
I just commited the stuff that I created. Basically it is the same approach as yours, except that I went a bit further and added both db api versions as libraries.
Furthermore I took both ser and kamailio mysql modules and integrated them into a single db_mysql module which supports both versions of the db API and links with both libraries. [..]
Hi Jan,
unfortunally i was not able to take a closer look to the stuff you commited, i'll try to comment later today. As already suggested i'd also think that we should perhaps try to reduce the number of branches, otherwise its hard to understand where the most up to date version is, what should be reviewed and tested..
Don't worry, my version is pretty much the same as Andrei's and what has already been described on the mailing list. The extra stuff that I did was unifying the mysql driver module so that it exports both interfaces.
The point of this discussion was namely to agree on naming convertions whether or not we want to go down that road. It seems to me that we have consensus here so I will proceed a bit further.
Regarding git and branches, IMHO this kind of independent concurrent development is one of the things git is really strong in. It does not really matter how many branches each of us have, the only really important branch at the moment is the master branch and all other features and developments done on other (private) branches is nothing more than just experimenting.
So right now there is nothing really like the most up-to-date version of proposed database changes. There will be once something is merged into the master and then we will have something to try and test.
Jan.
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
Henning Westerholt -
Jan Janak -
Jan Janak -
Klaus Darilion