[SR-Dev] DB decisions

[Andrei Pelinescu-Onciul]

On Nov 24, 2008 at 10:52, Henning Westerholt <henning.westerholt at 1und1.de> wrote:
> On Friday 21 November 2008, Andrei Pelinescu-Onciul wrote:
> > On Nov 21, 2008 at 04:34, Jan Janak <jan at iptel.org> wrote:
> > [...]
> >
> > >   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)?
> >
> > 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).

> 
> > >   2) 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