2017-09-14 3 views
5

La plupart des exemples de code montrant comment utiliser dplyr avec une base de données impliquent la création d'un objet de connexion de base de données:Utilisation dplyr avec base de données sans créer un explicite objet DBI

connStr <- "driver=driver;server=hostname;database=mydatabase;..." 
db <- DBI::dbConnect(odbc::odbc(), .connection_string=connStr) 

tbl <- tbl(db, "mytable") 
tbl %>% verb1 %>% verb2 %>% ... 

Cependant, supposons que j'omettez la création d'un objet db:

tbl <- tbl(DBI::dbConnect(odbc::odbc(), .connection_string=connStr), "mytable") 
tbl %>% verb1 %>% verb2 %>% ... 

Y a-t-il des conséquences à cela? Vais-je utiliser les ressources de base de données/mémoire de fuite/etc? Le SGBD que j'ai à l'esprit est SQL Server et le paquet de pilotes est odbc, au cas où cela serait important.

+0

La seule chose qui vient à l'esprit est qu'il devient très facile de laisser cette connexion ouverte. Cela peut ou peut ne pas être un problème sérieux pour vous. – Benjamin

Répondre

2

Le nouveau DBI specs suppose que l'appelant libère toutes les connexions qu'il attribue avec dbConnect() avec un appel correspondant à dbDisconnect(). Si vous ne le faites pas, la connexion ne sera fermée que pendant la récupération de place (ou la fin de la session R), ce qui retardera la libération des ressources ou provoquera même une fuite de la connexion.

Le comportement exact dépend du backend DBI impliqué (dans ce cas le paquet odbc). Selon Jim Hester, le mainteneur de odbc,

[il] appelle automatiquement dbDisconnect() lorsque l'objet de connexion est détruite, donc cela ne fuira pas les connexions. Si vous ouvrez un grand nombre de connexions, il est toujours préférable d'être explicite, si vous le faites de manière interactive, il est probablement correct de s'appuyer sur le garbage collector dans ce cas.