24 Nov
2008
24 Nov
'08
1:52 p.m.
On 24-11 13:37, Andrei Pelinescu-Onciul wrote:
On Nov 24, 2008 at 10:52, Henning Westerholt
<henning.westerholt(a)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.