Dplyr: Saya tidak dapat menghubungkan schema.table postgresql dengan paket dplyr

@hadley memikirkan jawaban Anda, saya datang untuk menulis kalimat SQL lengkap

my_tbl = tbl(my_db, dplyr::sql('SELECT * FROM mortalidad.def0307'))

dan di sana saya bisa terhubung ke skema dan tabel. Terima kasih banyak. – Diego

Saya baru saja akan memposting masalah yang sama ketika bekerja dengan Greenplum. Metode sql Anda memecahkan masalah saya.

Saya senang dengan itu. Satu-satunya hal yang membuat saya khawatir adalah bahwa dalam pernyataan sql berikut ini diamati:

SELECT "var1", count(*) AS "n" FROM (SELECT * FROM mortalidad.mort12)

ketika pengelompokan dilakukan. Ada subquery setelah FROM dan saya tidak tahu apakah ini akan memiliki masalah dengan efisiensi kueri sql. Saya seorang Ahli Epidemiologi dan saya tidak mengetahui hal ini.

Maukah Anda memberi saya urutan perintah SQL yang dapat saya jalankan di postgresql untuk membuat skema dan database dalam skema itu?

Maaf atas keterlambatan di sini saya kirim sebagai skema buat

BUAT TABEL schema_name.table_name
(
karakter codigo bervariasi (3),
karakter nombre bervariasi(51),
karakter benua bervariasi(7)
)

2014-03-19 18:56 GMT-03:00 Hadley Wickham [email protected] :

Maukah Anda memberi saya urutan perintah SQL yang bisa saya jalankan?
postgresql untuk membuat skema dan database dalam skema itu?

Balas email ini secara langsung atau lihat di Gi tHubhttps://github.com/hadley/dplyr/issues/244#issuecomment -38112148
.

Diego Garcilazo
Dokter
Departamento Programas de Salud
Instituto Nacional de Enfermedades Respiratorias
Av. Blas Parera 8260 // Santa Fe // Argentina //0342 - 4896850
http://www.anlis.gov.ar/inst/iner/

Saya pikir pada dasarnya ada dua opsi di sini:

1. Kasus khusus keluar setiap kali ada titik di pengidentifikasi. Ini berarti x.y akan lolos ke "x"."y" . Ini memiliki keuntungan karena sangat ringkas, memiliki kelemahan bahwa tabel yang diterjemahkan dari R ke SQL tidak dapat menggunakan . dalam nama bidang (mungkin tidak terlalu umum).
2. Gunakan mekanisme pelarian baru. Mungkin cara termudah untuk melakukannya adalah dengan memperluas ident() untuk mengambil beberapa argumen, misalnya ident("x", "y") . Atau dapat mendefinisikan dot() yang melakukan NSE untuk memungkinkan Anda menulis dot(x, y) . Ini lebih banyak mengetik, tetapi dijamin tidak akan merusak kode yang ada.

Ini penting baik untuk nama tabel (misalnya schema.table ) dan mungkin untuk membedakan nama bidang dalam gabungan (misalnya table.field )

Saat ini saya condong ke fungsi dot() eksplisit, karena mengubah cara kerja pelolosan secara global tampaknya berisiko.

Hmmmm, untuk kasus penggunaan ini, Anda bisa melakukan:

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

Dan beberapa kode lain untuk referensi di masa mendatang (tidak berhasil)

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"))

Hai Hadley,

Saya mengalami masalah yang sama dan sarang tampaknya menjadi masalah untuk kinerja (dalam kasus saya yang serius karena saya sedang mengerjakan data dengan 100 juta baris). Bisakah Anda menjelaskan mengapa percobaan terakhir Anda gagal?

Terima kasih

FWIW, untuk beberapa kasus penggunaan idiom yang bermanfaat adalah:

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

Kemudian kueri berikutnya yang menggunakan koneksi itu ada di dalam skema itu.

Hai Harlan,

terima kasih - dan saya sudah menggunakan sesuatu seperti itu (kecuali saya memperluas jalur pencarian dengan skema. Tapi sejauh ini hanya membantu. Jika Anda memiliki tabel dengan nama yang sama dalam 2 skema, tidak akan.

Bagaimanapun, saya bertanya-tanya mengapa tidak membebani tanda '$' di penerjemah SQL base_scalar.

Itu bahkan masuk akal dari sudut pandang r

a$b$c, akan ada lingkungan (yaitu skema), tabel ba dan kolom ca. Satu-satunya pemikiran yang harus diperbaiki adalah tbl_sql, yang seharusnya tidak memeriksa dengan cara yang begitu sederhana jika table_name ada di database. Sebagai gantinya, itu bisa memeriksa apakah pernyataan "SELECT" adalah bagian dari kueri SQL dan jika tidak, tambahkan SELECT * di depan dan periksa variabel dengan cara ini.

Dalam hal ini, seseorang bahkan dapat mengaktifkan NSE untuk fungsi tbl?

Oh ya, satu lagi komentar:

dbSendQuery

sering tidak bekerja untuk RJDBC (setidaknya dengan vertica). Kueri di atas, yaitu SET search_path TO ...

tidak mengembalikan hasil. dbSendQuery memang mengharapkannya. Untuk vertica, ini tidak berfungsi dan harus menggunakan dbSendUpdate. Apakah itu juga berlaku untuk MySQL (atau setidaknya dbSendUpdate tidak gagal untuk MySQL)?

Saya menyukai gagasan untuk membebani $ . Saya pasti akan memikirkannya ketika saya mengerjakan dplyr berikutnya.

@hhoeflin sudahkah Anda mencoba RPostgreSQL alih-alih RJDBC untuk berbicara dengan vertica?

Tidak - tidak tahu bahwa RPostgreSQL adalah opsi. Bagaimanapun - backend vertica sekarang sudah diimplementasikan untuk RJDBC. Sudah mencoba dan mengalami masalah karena tabel postgres yang coba diakses untuk mengetahui tabel mana yang ada dalam database yang tampaknya berbeda.

Ini perlahan diselesaikan melalui DBI: https://github.com/rstats-db/DBI/issues/24