Раст меня настолько расслабил, что я даже забыла, что в других языках зачем-то бывает жёсткое разделение на expressions и statements

Почему это бесит? Потому что это та же проблема что и с цветными функциями. Ты можешь использовать expression в statement, но ни в коем случае не наоборот, иначе... жопа отвалится, вот. Нельзя, и точка

(мне очень понадобилось в триггере sqlite выполнить insert по условию, но insert это statement, и case его не жрёт)

@mo что-то я не понял проблему про инсерт в кейс. Разверни!

@igor мне в триггере надо выполнить insert, только если предоставленное значение столбца не NULL. Ну или как-то заигнорить not null constraint violation, тоже сгодится

у меня есть табличка где жирные поля вынесены в отдельные таблицы, и слинкованы. А чтобы красиво и удобно читать и писать это, у меня есть вьюха с триггером INSTEAD OF INSERT

NULL для жирных полей пишется не отдельной строкой в отдельную таблицу, а вместо ключа-ссылки

@igor (зачем выносить: чтобы навесить UNIQUE и получить доморощенную дедупликацию, т.к. значения там реально много повторяются)

@igor о, кажется, это можно сделать с CTE. Изобразить new.column в виде таблицы с одной строчкой as (values (...)), и затем сделать insert into ... select ... where column not null

@mo sqlite не умеет делать столбец UNIQUE?

@igor умеет конечно. Но мне ж как-то надо хранить повторяющиеся значения! Поэтому выкидываю их в отдельную таблицу (где навешиваю UNIQUE) и в основную пишу только id записи

@mo@mastodon.ml @igor@social.jtalk.ru @mo@mastodon.ml @igor@social.jtalk.ru а зачем размывать логику? почему не просто в коде два инсерта в разные таблицы и потом коммит транзакции?

@igelko потому что так недостаточно красиво. А ещё этот код придется писать на Go

@igor

@igelko ну и (имхо) разложить данные куда надо — это как раз задача базы. В конце концов, я компилировала sqlite со всеми фичами, и я буду использовать все фичи!

@igor

@mo@mastodon.ml @igor@social.jtalk.ru по мне так вполне красиво - больше прозрачности в структурах данных, меньше неочевидного поведения при апдейте/делите. Но необходимость писать этот код на Go многое объясняет)

@igelko а апдейтов и делитов там быть не должно, база append-only by design

@igor

@igelko @mo я вот тоже думаю, что, возможно, архитектура неправильная. Непонятно, конечно, что там да как. Но получается, что в основной таблице некоторые записи, к каждой привязано несколько уникальных записей из отдельной таблицы, но при этом есть повторы в основной таблице. UNIQUE по двум столбцам может тогда?

@igor аэээ, нет, наоборот. В отдельной таблице уникальные записи, на каждую из которых ссылается несколько записей из основной таблицы. И это исключительно для экономии места, потому что иначе размер базы и индексов взрывается, и всё начинает ТОРМОЗИТЬ

@igelko

@mo @igelko ааа...

@mo @igelko тормозит именно sqlite? А если такое сделать на постгресс или мариадб? Не пробовали посмотреть? Интересно бы было посмотреть разницу.

@igor одной из моих первых задач было переделать то, что предыдущий чел написал под постгрес на sqlite, для упрощения деплоя...

@igelko

@mo @igelko Я давно не работал с sqlite и у меня, возможно стереотипное, ощущение, что sqlite годится только для каких-то локальных баз внутри приложения, где не надо быстро писать/читать большие объёмы данных.

@igor@social.jtalk.ru @mo@mastodon.ml у sqlite нет проблем с объёмами и можно работать и с большой базой. У него проблемы с многопоточностью - извольте, что называется, в вашем коде это всё разрулить.

@igelko если много мелких транзакций, то WAL это тоже разрулит. А вот эта оптимизация с дедупликацией это как раз попытка сделать транзакции поменбше, чтобы писать не строки, а айдишники. И она сработала %)

@igor

@mo@mastodon.ml @igor@social.jtalk.ru то есть всё уткнулось не в sqlite, а в рандомную запись на HDD (которая чудовищно медленная по современным меркам).

@igelko ну, да, HDD это просто причина почему sqlite не успевал вывозить поток записи. Но сервер пересобирать ради этого никто не будет, для его основной задачи (дебиан репа) хардов за глаза, а мой сервис там дополнение

@igor

@igor с момента, когда туда добавили WAL, он превратился во вполне себе производительную штуку, читатели и писатели перестали блокировать друг друга. Всё как у взрослых СУБД в общем %)

@igelko

@igor а вообще да, тормозил именно sqlite. И я его понимаю, база на несколько десятков гигов[1] на HDD это.... Не то, с чем можно быстро работать

[1] во время тестовых прогонов я наблюдала до 50, но дальше sqlite начинал сыпать ERR_BUSY, и код без ретраев скипал обработку этого блока данных

@igelko

@mo @igelko Ну вот и проблема, получается. Писать не успевает.

@igor тем не менее, если добавить примитивную ручную оптимизацию, всё он нормально успевает

@igelko

@mo @igelko а есть у sqlite какие-то буферы в память? Типа оперативки докинуть и не будет ERR_BUSY?

@igor у sqlite есть гарантии ACID, которые требуют чтобы если транзакция успешно завершилась, то данные были сохранены на диске. Можно конечно докинуть размер WAL-файлу, но WAL это далеко не оптимальное хранилище данных, и большой лог всё ещё сильнее затормозит. Оказалось, проще написать простенький exponential backoff ретрай на пишущие операции

@igelko

@mo@mastodon.ml @igor@social.jtalk.ru это вообще не поможет, если бутылочное горлышко - финальная запись. тут только снижать количество записываемых байт через нормализацию и делать back pressure механизм.

@igelko это ровно то что я и сделала. Ретраи блокировали горутину, пока база не освободится и не прожует запрос

Ну, может разве что выкидывать строчки в отдельную таблицу это не совсем нормальная форма, но нагрузку оно снижает

@igor

Пока писала придумала workaround. Буду инсертить (потенциально пустой) результат селекта :D

что значит не делить на expressions и statements? Ну например....

fn cursed() {
loop {
return if break { return return return; } else { break return }
}
return return return
}

...должно скомпилироваться (хотя я не проверяла)

(тут на самом деле бо́льшая часть кода unreachable)

Вот есть люди, которые любят баш, а я люблю SQL. Офигенная головоломка, скучно точно не будет

@mo так себе... и то и другое .. такая любовб может вырасти в большой геморрой, особненно если сутками в этом сидишь...

Есть и NoSQL и графы и очень много всякого - на все пропитываться любовью - чувств не хватит ))

@cetb skill issue на самом деле, так-то любить можно неограниченно много вещей. Вот внимание им всем постоянно уделять вряд-ли получится, это да

Итаак на следующий день я подебила эту проблему

Получился триггер с запросами такого уровня проклятости, что я ещё пожалуй подумаю прежде чем его кому-то показывать

Но я чертовски горда собой

@mo

@mo
Пожалуйста, скажи мне что это не опечатка)
Я не уверен было ли это в словотворчестве, но как человек который тоже подебил проблему и не одну, я не могу не умилиться

@WildPowerHammer это такое старое и широко употребимое словотворчество, что я его уже и не тегаю, а просто использую

@mo
Я почему то его ооочень редко вижу и по сему забываю