Dplyr: Я не могу подключить postgresql schema.table с пакетом dplyr

@hadley думает о вашем ответе, я подошел, чтобы написать полное предложение SQL

my_tbl = tbl (my_db, dplyr :: sql ('ВЫБРАТЬ * ИЗ mortalidad.def0307'))

и там я мог подключиться к схеме и таблице. Большое спасибо. - Диего

Я как раз собирался опубликовать ту же проблему при работе с Greenplum. Метод sql решил мою проблему.

Я доволен этим. Единственное, что меня беспокоит, это то, что в заявлении sql наблюдается следующее

ВЫБРАТЬ "var1", count (*) КАК "n" ИЗ (ВЫБРАТЬ * ИЗ mortalidad.mort12)

когда любая группировка сделана. После FROM есть подзапрос, и я не знаю, возникнут ли у него какие-либо проблемы с эффективностью запроса sql. Я эпидемиолог и не знаю об этом.

Не могли бы вы дать мне последовательность команд SQL, которые я могу запустить в postgresql для создания схемы и базы данных в этой схеме?

Извините за задержку здесь я отправляю как создать схему

СОЗДАТЬ ТАБЛИЦУ имя_схемы.имя_таблицы
(
различный характер кодиго (3),
переменный номинальный характер (51),
континентальный характер варьируется (7)
)

2014-03-19 18:56 GMT-03: 00 Хэдли Уикхэм [email protected] :

Не могли бы вы дать мне последовательность команд SQL, которые я могу запустить в
postgresql для создания схемы и базы данных в этой схеме?

Ответьте на это письмо напрямую или просмотрите его на Gi tHubhttps: //github.com/hadley/dplyr/issues/244#issuecomment -38112148
.

Диего Гарсиласо
Медико
Departamento Programas de Salud
Instituto Nacional de Enfermedades Respiratorias
Средний. Блас Парера 8260 // Санта-Фе // Аргентина // 0342-4896850
http://www.anlis.gov.ar/inst/iner/

Я думаю, здесь есть два основных варианта:

1. Особый случай, когда в идентификаторе есть точка. Это будет означать, что x.y перейдет в "x"."y" . Это имеет то преимущество, что оно очень краткое, а недостаток состоит в том, что таблицы, переведенные с R на SQL, не могут использовать . в именах полей (вероятно, не очень часто).
2. Используйте новый механизм побега. Вероятно, самый простой способ сделать это - расширить ident() чтобы он мог принимать несколько аргументов, например, ident("x", "y") . В качестве альтернативы можно определить dot() который выполняет NSE, чтобы вы могли писать dot(x, y) . Это больше похоже на набор текста, но гарантированно не нарушит существующий код.

Это важно как для имен таблиц (например, schema.table ), так и, возможно, для устранения неоднозначности имен полей в соединениях (например, table.field )

В настоящее время я склоняюсь к явной функции dot() , потому что изменение способа экранирования в глобальном масштабе кажется рискованным.

Хмммм, для этого варианта использования вы можете просто сделать:

my_tbl <- tbl(my_db, sql('mortalidad.def0307'))

И еще какой-то код для справки в будущем (не удалось)

dot <- function(...) {
  args <- dots(...)
  is_name <- vapply(args, is.name, logical(1))
  if (any(!is_name)) {
    stop("All arguments to dot() must be names.")
  }

  dots <- vapply(args, as.character, character(1))
  class(dots) <- c("ident_multi", "ident", "sql", "character")
  dots
}

dot <- function(...) {
  out <- paste(escape(c(...), parens = FALSE), collapse = ".")
  class(out) <- c("ident", "sql", "character")
  out
}

#' <strong i="6">@export</strong>
escape.ident_multi <- function(x, parens = FALSE, collapse = ", ", con = NULL) {
  y <- vapply(x, escape_ident, FUN.VALUE = character(1), con = con)
  paste(y, collapse = ".")
}

#' <strong i="7">@export</strong>
format.ident_multi <- function(x, ...) paste0("<SQL> ", paste(x, collapse = "."))

# lahman_sqlite() %>% tbl("Batting")
# lahman_sqlite() %>% tbl("main.Batting")
# lahman_sqlite() %>% tbl(sql("main.Batting"))
# lahman_sqlite() %>% tbl(dot("main", "Batting"))

Привет Хэдли,

У меня такая же проблема, и вложенность кажется проблемой для производительности (в моем случае серьезной, поскольку я работаю с данными со 100 миллионами строк). Не могли бы вы рассказать, почему ваша последняя попытка не удалась?

Спасибо

FWIW, для некоторых случаев использования полезная идиома:

dbSendQuery(con$con, build_sql("SET search_path TO ", schema_name))

Затем последующие запросы, использующие это соединение, находятся в этой схеме.

Привет, Харлан,

спасибо - и я уже использую что-то подобное (за исключением того, что я расширяю путь поиска по схеме. Но пока это только помогает. Если у вас есть таблицы с одинаковыми именами в двух схемах, этого не будет.

В любом случае, мне было интересно, почему бы не перегрузить знак «$» в SQL-переводчике base_scalar.

Это имело бы смысл даже с точки зрения r

a $ b $ c, это будет среда (т.е. схема), таблица ba и столбец ca. Единственное, что нужно исправить, - это tbl_sql, который не должен проверять таким простым способом, существует ли table_name в базе данных. Вместо этого он может проверить, является ли оператор «SELECT» частью SQL-запроса, а если нет, добавить перед ним SELECT * и таким образом проверить переменные.

В этом случае можно было бы даже включить NSE для функции tbl?

Ах да, еще один комментарий:

dbSendQuery

часто не работает для RJDBC (по крайней мере, с vertica). Вышеупомянутый запрос, т.е. SET search_path TO ...

не возвращает результат. dbSendQuery действительно ожидает этого. Для Vertica это не работает, и нужно использовать dbSendUpdate. Это также относится к MySQL (или, по крайней мере, dbSendUpdate не дает сбоев для MySQL)?

Мне нравится идея перегрузки $ . Я обязательно подумаю об этом, когда в следующий раз буду работать над dplyr.

@hhoeflin вы пробовали RPostgreSQL вместо RJDBC для разговора с vertica?

Нет - понятия не имел, что RPostgreSQL - это вариант. В любом случае - серверная часть vertica сейчас уже реализована для RJDBC. Хотя попытался и столкнулся с проблемами, поскольку таблицы postgres, к которым он пытается получить доступ, чтобы узнать, какие таблицы существуют в базе данных, кажутся разными.

Это медленно решается с помощью DBI: https://github.com/rstats-db/DBI/issues/24