[SR-Dev] DB decisions
jan at ryngle.com
Mon Nov 24 13:52:55 CET 2008
On 24-11 13:37, Andrei Pelinescu-Onciul wrote:
> On Nov 24, 2008 at 10:52, Henning Westerholt <henning.westerholt at 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
> 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
> k DB_BIGINT
> s DB_DOUBLE
> s DB_CSTR
> k DB_STRING - smae thing as ser DB_CSTR
> 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.
More information about the sr-dev