В чем разница между Query и RawQuery в Room?

Различие между Query и RawQuery в Room

В Android Room Persistence Library @Query и @RawQuery — это два аннотированных метода для выполнения SQL-запросов, но с фундаментальными различиями в типе безопасности, гибкости и сценариях использования.

@Query: Типобезопасный доступ к данным

@Query — это основной и рекомендованный способ выполнения запросов в Room. Он обеспечивает компиляционную проверку типов и синтаксиса SQL.

Ключевые характеристики:

• Валидация на этапе компиляции: Room проверяет SQL-синтаксис запроса и соответствие возвращаемого типа данных объявленному методу DAO.
• Параметризация: Параметры запроса передаются через аргументы метода и автоматически экранируются, что предотвращает SQL-инъекции.
• Простота использования: Прямая интеграция с LiveData, Flow (Kotlin Coroutines) и реактивными потоками.
• Ограничение: Запрос должен быть статическим и известным на этапе компиляции.

Пример использования @Query:

@Dao
interface UserDao {
    // Компилятор проверит, существует ли столбец 'name' в таблице 'users'
    @Query("SELECT * FROM users WHERE name = :userName")
    fun getUserByName(userName: String): User

    // Поддержка реактивных потоков
    @Query("SELECT * FROM users WHERE age > :minAge")
    fun getAdultUsers(minAge: Int): Flow<List<User>>

    // Запрос с несколькими параметрами
    @Update
    @Query("UPDATE users SET status = :status WHERE id = :userId")
    suspend fun updateUserStatus(userId: Long, status: String)
}

@RawQuery: Динамические запросы во время выполнения

@RawQuery предоставляет механизм для выполнения динамических SQL-запросов, которые формируются во время выполнения приложения.

Ключевые характеристики:

• Динамическое построение запросов: Позволяет собирать SQL-запросы по частям на основе логики приложения (например, добавление условий WHERE в зависимости от фильтров).
• Отсутствие компиляционной проверки: Синтаксис SQL не проверяется компилятором, что увеличивает риск ошибок времени выполнения.
• Ручное управление: Разработчик самостоятельно управляет параметрами и маппингом результатов.
• Использование SupportSQLiteQuery: Запрос оборачивается в объект SupportSQLiteQuery, который может быть построен с помощью SimpleSQLiteQuery.

Типичные сценарии использования @RawQuery:

• Сложные динамические фильтры с нефиксированным количеством условий.
• Запросы, где структура SELECT может меняться.
• Миграции сложных данных или кастомные агрегации.

Пример динамического запроса с @RawQuery:

@Dao
interface UserDao {
    @RawQuery
    fun getUsersDynamic(query: SupportSQLiteQuery): List<User>

    // Функция для построения динамического запроса
    fun getUsersFiltered(name: String?, minAge: Int?): List<User> {
        val queryBuilder = StringBuilder("SELECT * FROM users WHERE 1=1")
        val args = mutableListOf<Any>()

        name?.let {
            queryBuilder.append(" AND name LIKE ?")
            args.add("%$it%")
        }
        minAge?.let {
            queryBuilder.append(" AND age >= ?")
            args.add(it)
        }

        val query = SimpleSQLiteQuery(queryBuilder.toString(), args.toTypedArray())
        return getUsersDynamic(query)
    }
}

Сравнительная таблица

Рекомендации по выбору

1. Всегда отдавайте предпочтение @Query, когда запрос известен на этапе компиляции. Это обеспечивает безопасность и удобство поддержки.
2. Используйте @RawQuery только в исключительных случаях, когда невозможно выразить запрос через @Query из-за его динамической природы.
3. При работе с @RawQuery обязательно:
   • Используйте параметризованные запросы (? или named parameters) для предотвращения SQL-инъекций.
   • Тщательно тестируйте все возможные варианты формирования запроса.
   • Документируйте логику построения динамических запросов.

Итог: @Query — это безопасный, проверяемый "путь по шоссе" для большинства потребностей приложения, в то время как @RawQuery — это "внедорожный инструмент" для особых случаев, требующий профессионального обращения и повышенной ответственности разработчика.