bigrquery - Ошибка: нет подходящей подписи для оператора - для типов аргументов: DATE, FLOAT64 - PullRequest
Новая
       81

bigrquery - Ошибка: нет подходящей подписи для оператора - для типов аргументов: DATE, FLOAT64

0 голосов
/ 10 апреля 2020

Когда filter(), используя дату и используя функцию для предоставления этой даты, я вижу ожидаемую ошибку: 

library(tidyverse)
library(bigrquery)

table1 %>% 
  filter(date > as.character(today() - 730)) %>% 
  tally()

# Error: No matching signature for operator - for argument types: DATE, FLOAT64. 
Supported signatures: INT64 - INT64; NUMERIC - NUMERIC; FLOAT64 - FLOAT64 at [29:29] [invalidQuery]

, но когда дата указана в виде строки, она отлично работает 

table1 %>%
  filter(date > '2018-04-11') %>% 
  tally()

#          n
#      <int>
#  623451234

Я могу подтвердить, as.character(today() - 730) и '2018-04-11' одинаковы 

> identical(as.character(today() - 730), '2018-04-11')
[1] TRUE

Следующий обходной путь приемлем, но становится загроможденным для больших баз кода: 

date_from <- as.character(today() - 730)

table1 %>% 
  filter(date > date_from) %>% 
  tally()

Вопрос

Почему мы видим ошибку, когда дата предоставляется filter() с помощью функции, подобной as.character(today() - 730), но не когда дата предоставляется строкой?

Примечания

  • аналогичный вопрос здесь
  • Я попытался заменить as.character(today() - 730) на as.Date(today() - 730) и получил точно такую ​​же ошибку

1 Ответ

1 голос
/ 11 апреля 2020

Вы отметили это как dbplyr, хотя в вашем вопросе об этом нет упоминания. Если вы используете dbplyr, то проблема связана с тем, как dbplyr переводит с R на язык базы данных (в вашем случае это большой запрос).

dbplyr имеет ряд встроенных переводов, которые делают преобразование (например, filter переводится в WHERE предложения). Эти переводы могут искать значения из переменных в соответствии с вашим примером: 

date_from <- as.character(today() - 730)
table1 %>% filter(date > date_from)

Но не могут сказать подфункциям, следует ли оценивать, переводить или оставить как есть. Следовательно, согласно этой документации dbplyr оставляет любые "неизвестные" функции как есть. Это означает, что 

table1 %>% filter(date > as.character(today() - 730))

, вероятно, переводится в нечто вроде 

SELECT ...
FROM ...
WHERE date > as.character(today() - 730)

, что приводит к ошибке, так как это недопустимый синтаксис для базы данных.

Вы можете проверить перевод с использованием show_query(): 

table1 %>% filter(date > as.character(today() - 730)) %>% show_query()

Этот вопрос задает очень похожую проблему - переводы определяются для функций, которые они используют, но не для пользовательских функций, которые действует как обертка. Возможность определения пользовательских переводов решит оба вопроса, но в настоящее время это представляется невозможным.

Существует два обходных пути:

  1. Из документации dbplyr Вы можете использовать sql() для вставки необработанной строки SQL (которая не будет переведена).
  2. Вы можете написать свои собственные функции, которые возвращают пользовательские определения таблиц. См. Раздел «Создание пользовательских функций» этого ответа .
...