Dplyr: لا يمكنني الاتصال postgresql schema.table مع حزمة dplyr

hadley أفكر في إجابتك جئت لكتابة جملة SQL كاملة

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

وهناك يمكنني الاتصال بالمخطط والجدول. شكرا جزيلا. - دييجو

كنت سأقوم بنشر نفس المشكلة عند العمل مع Greenplum. لقد حلت طريقة SQL مشكلتي.

أنا سعيد بذلك. الشيء الوحيد الذي يقلقني هو أنه في بيان SQL يتم ملاحظة ما يلي

حدد "var1"، count (*) AS "n" FROM (SELECT * FROM mortalidad.mort12)

عندما يتم أي تجميع. يوجد استعلام فرعي بعد FROM ولا أعرف ما إذا كان هذا سيواجه أي نوع من المشاكل مع كفاءة استعلام sql. أنا متخصص في علم الأوبئة ولا علم لي بذلك.

هل تمانع في إعطائي سلسلة من أوامر SQL التي يمكنني تشغيلها في postgresql لإنشاء مخطط وقاعدة بيانات في هذا المخطط؟

آسف للتأخير هنا أرسلته كإنشاء مخطط

إنشاء اسم الجدول schema_name.table_name
(
أحرف codigo متفاوتة (3) ،
حرف nombre متفاوتة (51) ،
الأحرف القارية متفاوتة (7)
)

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

هل تمانع في إعطائي سلسلة من أوامر SQL التي يمكنني تشغيلها
postgresql لإنشاء مخطط وقاعدة بيانات في هذا المخطط؟

قم بالرد على هذه الرسالة الإلكترونية مباشرة أو tHubhttps: //github.com/hadley/dplyr/issues/244#issuecomment -38112148
.

دييغو جارسيلازو
ميديكو
Departamento Programas de Salud
المعهد الوطني للأنفيرميدادس الجهاز التنفسي
Av. بلاس باريرا 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))

ثم تكون الاستعلامات اللاحقة باستخدام هذا الاتصال ضمن هذا المخطط.

مرحبا هارلان ،

شكرًا - وأنا أستخدم شيئًا من هذا القبيل بالفعل (باستثناء أنني أقوم بتوسيع مسار البحث بواسطة المخطط. ولكنه يساعد فقط حتى الآن. إذا كان لديك جداول بنفس الأسماء في مخططين ، فلن يحدث ذلك.

على أي حال ، كنت أتساءل لماذا لا تفرط في تحميل علامة "$" في مترجم base_scalar SQL.

سيكون من المنطقي حتى من منظور r

أ $ b $ c ، سيكون هناك بيئة (أي مخطط) وجدول ba وعمود ca. الاعتقاد الوحيد الذي يجب إصلاحه هو tbl_sql ، والذي لا ينبغي التحقق منه بهذه الطريقة البسيطة إذا كان اسم الجدول موجودًا في قاعدة البيانات. بدلاً من ذلك ، يمكنه التحقق مما إذا كانت عبارة "SELECT" جزءًا من استعلام SQL وإذا لم تكن كذلك ، فقم بإضافة SELECT * في المقدمة وتحقق من المتغيرات بهذه الطريقة.

في هذه الحالة ، يمكن للمرء حتى تمكين NSE لوظيفة tbl؟

أوه نعم ، تعليق آخر:

dbSendQuery

غالبًا لا يعمل مع RJDBC (على الأقل مع رأسي). الاستعلام أعلاه ، أي تعيين search_path TO ...

لا يعود نتيجة. يتوقع dbSendQuery واحدًا. بالنسبة إلى Vertica ، لا يعمل هذا ويجب على المرء استخدام dbSendUpdate. هل هذا هو الحال أيضًا بالنسبة لـ MySQL (أو على الأقل هل dbSendUpdate لا يفشل مع MySQL)؟

تعجبني فكرة التحميل الزائد على $ . سأفكر في الأمر بالتأكيد عندما أعمل بعد ذلك على dplyr.

hhoeflin هل جربت RPostgreSQL بدلاً من RJDBC للتحدث إلى Vertica؟

لا - ليس لدي فكرة أن RPostgreSQL يعد خيارًا. على أي حال - تم تنفيذ الواجهة الخلفية الرأسية الآن لـ RJDBC بالفعل. خضعت للتجربة وواجهت مشاكل لأن جداول postgres التي تحاول الوصول إليها لاكتشاف الجداول الموجودة في قاعدة البيانات تبدو مختلفة.

يتم حل هذا الأمر ببطء من خلال DBI: https://github.com/rstats-db/DBI/issues/24