Используйте dplyr с базой данных без создания явного объекта DBI

Большинство примеров кода, показывающих, как использовать dplyr с базой данных, включают создание объекта подключения к базе данных:

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

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

Однако предположим, что я опускаю создание объекта db:

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

Есть ли последствия этого? Буду ли я использовать ресурсы базы данных/утечку памяти/и т. д.?

Я имею в виду СУБД SQL Server, а пакет драйверов — odbc, если это имеет значение.


r odbc sql-server dplyr r-dbi
person Hong Ooi    schedule 14.09.2017    source источник
comment
Единственное, что приходит на ум, так это то, что становится очень легко оставить это соединение открытым. Это может или не может быть серьезной проблемой для вас.   -  person Benjamin    schedule 14.09.2017

Ответы (1)


arrow_upward
2
arrow_downward

Новые спецификации DBI предположим, что вызывающая сторона освобождает все соединения, которые они выделяют с помощью dbConnect(), с соответствующим вызовом dbDisconnect(). В противном случае соединение будет закрыто только во время сборки мусора (или в конце сеанса R), что приведет к задержке освобождения ресурсов или даже утечке соединения.

Точное поведение зависит от задействованной серверной части DBI (в данном случае пакета odbc). По словам Джима Хестера, сопровождающего odbc,

[он] автоматически вызывает dbDisconnect(), когда объект соединения удаляется сборщиком мусора, поэтому это не приведет к утечке соединений. Если вы открываете большое количество соединений, всегда лучше быть явным, если вы просто делаете это в интерактивном режиме, вероятно, в этом случае можно полагаться на сборщик мусора.

person krlmlr    schedule 15.09.2017