[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

How many people are still using Rdbi? 

It has long been superseded by 
DBI. One long standing reason for not moving to DBI was that there
was no support for PostgreSQL in the DBI world for a long time. But
this has changed recently with RPostgreSQL now available on CRAN.
Now the question is how good is RPostgreSQL these days? Is it mature
enough to be worth migrating apps from Rdbi/RdbiPgSQL to
DBI/RPostgreSQL? Is it something you've considered/tried?

Maybe it's time for us to deprecate Rdbi/RdbiPgSQL?

Feedback from 
other "PostgreSQL within R" users would be appreciated.

Hi Herv?,

How many people are still using Rdbi?

mmm ... no idea. The stats do show a downward sloping trend, that much is
clear.

It has long been superseded by
DBI. One long standing reason for not moving to DBI was that there
was no support for PostgreSQL in the DBI world for a long time. But
this has changed recently with RPostgreSQL now available on CRAN.
Now the question is how good is RPostgreSQL these days? Is it mature
enough to be worth migrating apps from Rdbi/RdbiPgSQL to
DBI/RPostgreSQL? Is it something you've considered/tried?

No, I wasn't aware of this, I will look into it.

Maybe it's time for us to deprecate Rdbi/RdbiPgSQL?

I think that is probably the case, but at the same time I would argue that
simply changing the .onLoad() function to an empty one (or deleting it, dunno
what's best) solves a design error that would at least help the current
users.

Feedback from
other "PostgreSQL within R" users would be appreciated.

Certainly. Thanks,



                                                                        Philip