> > As a side-note, one must be careful when converting to the new > > interface. If just the dbi_initialize_r() is used but the others use > the > > old functions, there is a lot of trouble. I ran myself into it. > > Unfortunately, I have no smart idea how to circumvent it. The > deprecated > > macros will probably help... ;) > > > > A half-assed way to circumvent this problem is to have > dbi_initialize_r set dbi_inst_legacy in addition to the structure > pointed to by **Inst. This will allow to run the old functions safely > and correctly as long as the initialization function is called only > once. However, this way we'll probably help to cover up many > incomplete migration attempts, so it may be more prudent to have the > apps crash right away so they get fixed.
I thought about that, but the "as long as the init function is called only once" is indication of a subtle problem with it. Consider this: - thinking about a plug-in system - still assume that the loader keeps a single static data area in memory no matter how many plugins use libdbi - there is *exactly* one plugin that uses the Old interface - there is one or more plugins using the new Interface In that situation, without the flag, everything works ok because the old interface plugin finds everything as expected. With a flag, the first call to dbi_initialize_r would kind of disable the old style interface calls, thus giving the old interface plugin a hard time. Granted, it is a very very unusual case, probably never to be seen in practice. It's also questionable if keeping things happy in that case outweights the benefits of another solution. But together with your thoughts on preventing incomplete migration attempts it probably adds to solid reasoning NOT to support such a flag. I just wanted to pass the info, hopefully its useful. Rainer ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ libdbi-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libdbi-devel
