[Bioc-devel] cyclic dependency bug in Rdbi

Dear all,

We use Rdbi often, and I keep coming across the rather inconvenient ''cyclic
name space dependencies are not supported'' error. I decided to get to the
bottom of this, and basiscally the problem is that Rdbi's .onLoad() function
always tries to call dbReconnect(obj), even if the .onLoad() is being called
recursively. The latter happens if an R data file (e.g. .RData) contains an
object that has a class which is not yet loaded. Once the object is loaded,
and then inspected, R loads the class definitions of that object. If the
object's class depends on Rdbi, then it will of course load Rdbi. But in
doing so, Rdbi's .onLoad() function will try to dbReconnect(obj). But obj
cannot be accessed without loading all its class definitions, which leads to
a recursive call to loadNamespace("Rdbi"), triggering the circular
dependency.

I see four solutions:

   (1) Never put 'Depends: Rdbi' in a class's DESCRIPTION. (not a solution,
       IMHO)

   (2) Force people to call library(Rdbi) before load()ing anything (no
       solution either; people forget that, then bother the local R guru's
       again)

   (3) Don't call dbReconnect() in Rdbi's .onLoad() (see below)

   (4) Make Rdbi's  .onLoad() function a bit cleverer (this will take work)

I would really appreciate if this error would go away; many different people
seem to be bitten by it time and again (also many GRASS users seem to suffer
it).  I much prefer solution 3; I frankly think that blindly reconnecting a
database connection from a saved object is plain wrong. After all, people
often save an object to disk exactly because they don't want to have to
connect to a database. In addition, I think it's hard to make this work
robustly, as evidenced by the cyclic dependency error. (If needed I have a
simple worked example reproducing the bug).

I may of course have overlooked something; please let me know if that is the
case.

I contacted the maintainer, but he hasn't responded yet, but the issue maybe
requires wider consideration anyway.

Regards,
                                                                        Philip