Dplyr: Je ne peux pas connecter postgresql schema.table avec le package dplyr

@hadley pensant à votre réponse, je suis venu pour écrire la phrase SQL complète

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

et là, je pouvais me connecter au schéma et à la table. Merci beaucoup. – Diégo

J'allais justement poster ce même problème lorsque je travaillais avec Greenplum. Votre méthode SQL a résolu mon problème.

Je suis content de ça. La seule chose qui m'inquiète, c'est que dans l'instruction sql ce qui suit est observé

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

lorsqu'un regroupement est effectué. Il y a une sous-requête après FROM et je ne sais pas si cela posera un problème avec l'efficacité de la requête SQL. Je suis épidémiologiste et je ne suis pas au courant.

Pourriez-vous me donner une séquence de commandes SQL que je peux exécuter dans postgresql pour créer un schéma et une base de données dans ce schéma ?

Désolé pour le retard ici, j'envoie en tant que créer un schéma

CREATE TABLE nom_schéma.nom_table
(
caractère codigo variable(3),
nombre caractère variable(51),
caractère continental variable(7)
)

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

Pourriez-vous me donner une séquence de commandes SQL que je peux exécuter
postgresql pour créer un schéma et une base de données dans ce schéma ?

Répondez directement à cet e-mail ou consultez-le sur Gi tHubhttps://github.com/hadley/dplyr/issues/244#issuecomment -38112148
.

Diego Garcilazo
Médico
Departamento Programas de Salud
Instituto Nacional de Enfermedades Respiratorias
Un V. Blas Parera 8260 // Santa Fe // Argentine //0342 - 4896850
http://www.anlis.gov.ar/inst/iner/

Je pense qu'il y a essentiellement deux options ici:

1. Cas particulier s'échappant à chaque fois qu'il y a un point dans l'identifiant. Cela signifierait que x.y serait un échappement à "x"."y" . Cela a l'avantage d'être très succinct, cela a l'inconvénient que les tables traduites de R en SQL ne peuvent pas utiliser . dans les noms de champs (probablement pas très courant).
2. Utilisez un nouveau mécanisme d'échappement. Le moyen le plus simple de le faire serait probablement d'étendre ident() pour prendre plusieurs arguments, par exemple ident("x", "y") . Vous pouvez également définir dot() qui fait NSE pour vous permettre d'écrire dot(x, y) . C'est plus de frappe, mais il est garanti de ne casser aucun code existant.

Ceci est important à la fois pour les noms de table (par exemple schema.table ) et éventuellement pour lever l'ambiguïté des noms de champ dans les jointures (par exemple table.field )

Je penche actuellement vers la fonction explicite dot() , car changer le fonctionnement global de l'échappement semble risqué.

Hmmmm, pour ce cas d'utilisation, vous pouvez simplement faire :

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

Et un autre code pour référence future (n'a pas réussi)

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

Salut Hadley,

J'ai le même problème et l'imbrication semble être un problème de performances (dans mon cas, un problème grave car je travaille sur des données avec 100 millions de lignes). Pourriez-vous expliquer pourquoi votre dernier essai a échoué ?

Merci

FWIW, pour certains cas d'utilisation, un idiome utile est :

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

Ensuite, les requêtes suivantes utilisant cette connexion se trouvent dans ce schéma.

Salut Harlan,

merci - et j'utilise déjà quelque chose comme ça (sauf que j'étends le chemin de recherche par le schéma. Mais cela n'aide que jusqu'à présent. Si vous avez des tables avec les mêmes noms dans 2 schémas, ce ne sera pas le cas.

Quoi qu'il en soit, je me demandais pourquoi ne pas surcharger le signe '$' dans le traducteur SQL base_scalar.

Cela aurait même du sens d'un point de vue r

a$b$c, il y aurait un environnement (c'est-à-dire un schéma), une table ba et une colonne ca. Le seul problème qui doit être corrigé est alors tbl_sql, qui ne devrait pas vérifier d'une manière aussi simple si le nom_table existe dans la base de données. Au lieu de cela, il pourrait vérifier si une instruction "SELECT" fait partie de la requête SQL et sinon, ajouter un SELECT * devant et vérifier les variables de cette façon.

Dans ce cas, on pourrait même activer NSE pour la fonction tbl ?

Ah oui, encore un commentaire :

dbEnvoiRequête

ne fonctionne souvent pas pour RJDBC (au moins avec vertica). La requête ci-dessus, c'est-à-dire SET search_path TO ...

ne renvoie pas de résultat. dbSendQuery en attend un. Pour vertica, cela ne fonctionne pas et il faut utiliser dbSendUpdate. Est-ce également le cas pour MySQL (ou du moins dbSendUpdate n'échoue-t-il pas pour MySQL) ?

J'aime l'idée de surcharger $ . J'y penserai certainement la prochaine fois que je travaillerai sur dplyr.

@hhoeflin avez-vous essayé RPostgreSQL au lieu de RJDBC pour parler à vertica ?

Non - je ne savais pas que RPostgreSQL était une option. Dans tous les cas, le backend vertica est déjà implémenté pour RJDBC. J'ai essayé cependant et j'ai rencontré des problèmes car les tables postgres auxquelles il essaie d'accéder pour savoir quelles tables existent dans la base de données semblent être différentes.

Cela se résout lentement via DBI : https://github.com/rstats-db/DBI/issues/24