Roman @3draven@mtdn.anyqn.com

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

Но serde сериализация и обратно и так для почти всех типов есть или ее можно легко сделать. Я десериализатор написал только что бы оперток не плодить

При этом десериализаторы писать элементарно, они автоматом фактически делаются.

fn deserialize_language_identifier<'de, D>(deserializer: D) -> Result<LanguageIdentifier, D::Error>
where
D: Deserializer<'de>,
{
let s: String = Deserialize::deserialize(deserializer)?;
s.parse().map_err(serde::de::Error::custom)
}

Может и макрос для совсем автомата накатать или найти.

Так и есть, diesel только порождает кучу дурной работы.

pub fn get_user(username: &str) -> Result<UserDb> {
DB_POOL.get_connection()?.query_row_and_then(
sql_fabric::get_user_sql(),
named_params! {":username":username},
|row| -> Result<UserDb> { from_row::<UserDb>(row).context("Get user info error") },
)
}

А вот так выглядит весь маппинг. Именнованные параметры есть, а выход мапится автоматом по совпадению имен...правда я еще не проверил работает ли :)

rusqlite+serde_ruslite легко решают все, что надо с автомапингами, при этом по дороге бесплатно есть сериализация и обратно если надо, куда угодно, не только с базой. Красота. Кажется.

Боже, благослови git и Торвальдса! Откатил два коммита назад что бы не вычищать дизель.

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

Включил фильм Затоичи. Блин, какой класс

Была мысль все к нему свести, но я пока не знаю возможно ли это, спеку читать надо, а ее я читать буду как РОС поднимется с колен.

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

Ну, то есть их много, но до них доживать еще далеко.

Вообще, я бы продолжил впиливание дизеля, но надо что бы мозги постепенно решили, что спать пора. После дизеля, в целом останется вероятно десериализатор один для серде запилить хитрый...или нет, как пойдет. Шобы потом оно как-то там все само. И наверное можно доделать уже два самых важных эндпоинта, а то там раскуроченные заготовки лежат, в которых пятьдесят "а вот так если?". Но уже почти все готово к тому что бы нудно пилить по очереди. Никаких "ой хочу еще это" пока нет.

Заклинатель помоек

#словотворчество

Хочу кабана в шоколаде!

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

Конечно мне не нравится, что diesel строит AST каждый раз и только потом вроде как решает, что запрос уже построен и можно переиспользовать, но погляжу как это будет на практике, на самом деле эндпоинты в этих системах отвечают долго и прям быстрого ответа не требуют, так что может и пойдет.

Любопытное.

https://www.opennet.ru/opennews/art.shtml?num=61655

Зато для поддержки постгри потом не придется пилить трейт на каждый вариант с репозиториями, а то я уже опечалился этим. Пришлось бы делать трейт фабрики запросов, и две реализации, в целом не сложно, но возня. Попробую к дизелю привыкнуть.

Правда дизель помедленнее чем rusqlite, но там такие разницы, что для хэловорда пофиг.