RDBC libodbc++ integration.
Apr 18 2002
Dennis Box


Problem:  RDBC depends on libodbc++ , a free software package which is poorly
supported.  Libodbc++ migration to new compiler and OS releases problematic.


Proposed solution: absorb functionality of libodbc++ into RDBC. Eliminate
redundant and/or unused code.

Steps:  

1) I was able to move libodbc++ source files from thier original GNU automake 
style development environment into an RDBC subdirectory and build 
libodbc++.so library using SRT  without difficulty.  
Time estimate: done/1 day(to do checkins, verify libraries get moved 
to proper place for release, etc)

2) Absorbing and eliminating (i.e. refactoring) code from a complex system 
like RDBC/libodbc++ requires assurance that functionality is not lost and 
that new bugs are not introduced.  SRT has a 'test' target that is used
successfully at other experiments for doing this. (GNU Automake has a 'check'
target for doing the same thing that the oracle_odbc driver uses).

Libodbc++ has a 'test' directory which can serve as a basis for many
of these tests, though they are not integrated into the GNU  make check 
testbed.
	2a) set up a gmake test suite for RDBC/libodbc++ subdirectory
	and a gmake check suite for libodbc++ that run the same tests.

Time estimate: 1 week?
I tried to set this up for the SRT-ized libodbc++ last night but I 
didn't quite get it working. 

	2b) attack the buglist 
http://www-numi.fnal.gov/fnal_minos/computing/oo_discussions/bug_tracking/bg0007.html 
 
	fix reported software problem (i.e. buglist)
	write test(s)
	gmake test step, verifying fix didnt break anything else	
	fix discrepancies, if any
	repeat

Time estimate: ongoing, as bugs are expected to crop up as software
is more heavily used, and features are added that create problems not
covered by existing tests.


NB at CDF they have scripts that grep the nightly build log for 'FAILED'
from the gmake test stage, and then email a notice to the developers 
that have CVS checkin permission.


ADVANTAGES
	We get control of libodbc++ and are free to fix bugs, particularly
	some of the getXXXX macros, one of which is on the buglist

	SRT makefiles are better understood by most minos collaberators
	than are GNU-Automake

DRAWBACKS

	We are 'forking' the code!  If the developer decides to make 
	changes and upgrades, we have to decide whether it is worth
	the (possibly considerable) effort to fold his changes in to ours.