LINUX.ORG.RU

Релиз Diesel 2.3.0

 diesel, , ,


0

4

Diesel — это безопасный, высокопроизводительный и расширяемый ORM и генератор SQL-запросов для языка Rust. Diesel гарантирует корректность генерируемых SQL-запросов и совместимость между типами, используемыми в коде приложения, и типами в БД. Код, который сгенерировал бы падающий запрос, попросту не скомпилируется. При этом, Diesel является zero-cost абстракцией: производительность кода, использующего Diesel такая же, как производительность кода на C, напрямую вызывающего SQL-запросы.

Основные нововведения в релизе 2.3.0

Новый макрос #[derive(HasQuery)]

Позволяет использовать структуру напрямую для генерации SQL-запроса.

use crate::schema::users;

#[derive(HasQuery)]
struct User {
    id: i32,
    name: String,
}

let users = User::query().load(connection)?

Раньше для в этом случае нужно было применять дерайвы Queryable и Selectable и использовать более громоздкий вызов users::table.select(User::as_select())

Поддержка оконных функций

Наконец-то Diesel поддерживает из коробки генерацию SQL с оконными функциями. Например, код

employees::table
    .select(
        dsl::rank()
            .partition_by(employees::department)
            .window_order(employees::salary.desc())
            .frame_by(dsl::frame::Rows.frame_starts_with(dsl::frame::UnboundedPreceding))
    )

сгенерирует следующий SQL-запрос:

SELECT
   RANK() OVER(PARTITION BY department ORDER BY salary DESC ROWS UNBOUNDED PRECEDING
FROM 
   employees

Разумеется, есть поддержка определений новых оконных функций:

#[declare_sql_function]
extern "SQL" {
    #[window]
    fn row_number() -> BigInt;
}

Поддержка SQLite в WASM

Diesel теперь поддерживает SQLite в любом WASM-рантайме, включая веб-браузеры.

Поддержка дополнительных типов для PostgreSQL

Добавлена поддержка типов RANGE и MULTIRANGE и операций над этими типами.

Поддержка JSON и JSONB для SQLite

Добавлена поддержка типов и функций JSON и JSONB для SQLite.

>>> Подробности

★★★★★

Проверено: CrX ()
Последнее исправление: dataman (всего исправлений: 3)
Ответ на: комментарий от provaton

На голом скл по сути будет то же самое

Ну вот, чуть больше ручной работы, зато лишний ненужный слой абстракции можно выкинуть, и лишнюю зависимость заодно. На сложных запросах код с ормом будет очень страшный и запутанный, так что выйдет паритет. Темплейты вполне можно использовать для подобных задач , я тоже так делал (самопальные вообще). Но в общем случае это плохая идея. Не должно быть слишком много сборки SQL, это как раз признак говнокода.

bread
()
Ответ на: комментарий от bread

Фактически, чтобы написать код с ORM, надо уже достаточно неплохо понимать SQL. Писать сложные запросы тяжело, что на чистом SQL, что на ORM, при использовании ORM трудоёмкость возрастает где-то вдвое. Мне уже лет 10 проще сначала написать чистый SQL запрос, а затем уже перевести его в ORM, если речь идёт о сложном запросе.

Невозможно писать ORM код не понимая SQL. Наверное, для очень простых запросов будет работать, но уже на первом же подзапросе будет конкретный затык.

Сейчас уже молодёжь впрочем переводит между ORM и SQL используя ИИ. Я, кстати, ради интереса несколько раз пробовал - довольно хорошо работает, к моему сожалению. Сложные вещи, которые напрягает писать руками (типа, напиши то же самое, но испольуя CTE, то же самое, но используя подзапросы), оно делает достаточно хорошо. Велик соблазн постоянно прибегать, вместо того, чтобы самостоятельно мозг морщить каждый раз.

Chiffchaff
()
Ответ на: комментарий от bread

Ну вот, чуть больше ручной работы

я тоже так делал (самопальные вообще)

По сути ты просто костылишь свой собственный query builder, только который не имеет никакой логической структуры, не имеет никакого предохранения от генерации неправильного синтаксиса, от ошибок с подстановкой значений. Да и скл инъекцию можно очень легко при таком подходе провтыкать. То есть, ты не убрал «лишний ненужный слой абстракции», ты его заменил на свой собственный через одно место реализованный.

Не должно быть слишком много сборки SQL, это как раз признак говнокода.

Но ты ведь не предложил никакой альтернативы для данной задачи. Или ты считаешь, что ее принципиально невозможно без говнокода решить?

provaton ★★★★★
() автор топика
Ответ на: комментарий от mord0d

Не надо было летней заправляться

Писать на расте не заправляясь невозможно.

Alphaer ★★
()
Ответ на: комментарий от bread

Я сегодня уволился с работы, где используются самописные query build’еры, в т.ч. на шаблонах. Это ужас-ужас.

Увольнялся не поэтому, конечно, но это тоже повлияло на решение. Зачем мне изучать кастомный query builder, построенный из костылей, склееных изолентой, если их уже написано вагон и маленькая телега: маленьких, больших, сложных, простых.

Этот кастомный велосипед ес-но:

  1. Не документирован (некогда документировать, код пилить надо!), в отличие от всех остальных существующих, его приходится изучать по коду
  2. Постоянно валится на всяких детских ошибках: добавил/удалил поле, и оно уже ляпнуло лишнюю запятую в запрос, или наоборот, не добавило.

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

Допускаю, что возможна обратная ситуация - в компании изобретают велосипед, потому что знают, что могут изобрести карбоновый невесомый аппарат, способный обогнать всех. Но эти компании у всех на слуху, не требуется специальной экспертизы, чтобы понять, что дурью типа query builder’ов на строковой конкатенации, там заниматься не будут.

Chiffchaff
()
Ответ на: комментарий от Chiffchaff

Так я не спорю, что ужас. Динамической генерации SQL в идеале вообще не должно быть. Но в особых случаях бывает приходится и наговнякать склейку. С ормом ты только этим и занимаешься через красивенький API. Ну щас по второму кругу пойдет этот вечный срач, мне уже поднадоело. Одна только неизбежная трансляция SQL <-> язык ORM, это уже приговор. Абстракция не просто протекает, она вытекла вся.

bread
()
Последнее исправление: bread (всего исправлений: 1)

Ну ждем Дизельгейта :)

gns ★★★★★
()
Ответ на: комментарий от bread

Но в особых случаях бывает приходится и наговнякать склейку.

Базовая задача адвансед серча по таблице - это «особый случай»? Ну-ну.

provaton ★★★★★
() автор топика

Rust — это то, на чём ядро Linux написано?

scanner
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.