[SR-Dev] DB decisions
andrei at iptel.org
Mon Nov 24 13:37:49 CET 2008
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 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
So far the conflicting macros/enums that I know about are
(s means present only in ser 2.1+, k only in kamailio, ' ' common):
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).
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.
More information about the sr-dev