на что недавно нарвался дак https://github.com/bitemyapp/esqueleto/issues/49 - промахнёшься с (обратным) порядком on/join и ошибка придёт только из БД, даже не исключение от Esqueleto

а так основная причина того, что пользуем persistent/esqueleto это MySQL, нормальные люди пользуют постгре и у них больше пространство для манёвра :)

А что постгресс дает, все равно же нужен DSL. Или для постгресса не нужен?)

дак говорю - больше пространство

ну с ходу могу назвать opaleye и hasql

тока pg

вроде ещё было что-то под pg и юзабельное

но копаем мускул, так что по теме pg я не советчик

Я довольно плохо ориентируюсь в экосистеме, поэтому opaleye - это открытие для меня, спасибо)

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

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

Да

Можно, но зачем?

@raventid я был

esqueleto расширяет список запросов, которые можно сделать persistent-ом до минимально разумного уровня

что вообще можно смотреть

но я вообще не люблю type safe выкрутасы поверх sql и orm

обычно это не работает

а я наоборот перекатал несколько десятков запросов с mysql-simple на persistent/esqueleto несколько недель назад

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

но осталась несколько ещё многоэтажных запросов которые не осилил :)

esqueleto расширяет список запросов, которые можно сделать persistent-ом до минимально разумного уровня

да, практика показывает, каким бы ни был орм, лучше писать запросы с оптимизацией сразу под задачу

Лучше для какой задачи?

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

А что с порядком джойнов? Inner joinы коммутативные же

Или mysql не оптимайзит такое?

Или mysql не оптимайзит такое?

Я могу ошибаться, но с джойнами движки обычно делают так. Допустим у тебя есть A join B join C join D 1. Выполняется только то, что запросил: джойнить A и C никто не будет 2. Приоритет всегда расставляется так, что результат — таблица (то есть (A j B) j (C j D) не будет)

если мне кто-нибудь скажет, что это не так, будет здорово. Могу приложить линк на лекции из уни, но в интернетах пруф пока не нашел (ищу)

да кодогенератор не может порядок проверять

в обычном сикеле у тебя по тексту идут JOIN а за ним ON

в esqueleto же они "оторваны" друг для друга, вроде как для композиционности

http://www.benjaminnevarez.com/2010/06/optimizing-join-orders/ Вот тут пишут что bushy не пользуются, потому что слишком много вариантов реордеринга

в итоге можешь делать JOIN для A и B, а в ON у тебя будут C и D

в тикете там всё вроде указано и линка на хаддоки, где ещё Фелипе задокументил косяк

Я могу ошибаться, но с джойнами движки обычно делают так. Допустим у тебя есть A join B join C join D 1. Выполняется только то, что запросил: джойнить A и C никто не будет 2. Приоритет всегда расставляется так, что результат — таблица (то есть (A j B) j (C j D) не будет)

зависит от оптимизатора запросов, хорошие перебирают варианты и оценивают стоимость

зависит от оптимизатора запросов, хорошие перебирают варианты и оценивают стоимость

Ну там перебрать можно только первые несколько итераций

bushy супердорого, да

в смысле итераций? если таблиц немного джойнится, то можно прикинуть cost для всех вариантов

если много (типа 10+), то всякие эвристики нужны уже

в итоге можешь делать JOIN для A и B, а в ON у тебя будут C и D

звучит странно, это уже другой какой-то джойн :)

в смысле итераций? если таблиц немного джойнится, то можно прикинуть cost для всех вариантов

Я потерялся. Что перебираем? У нас всегда дерево left-deep или right-deep. EDIT: посмотрел еще раз слайды, понял

ну не, возможно твое замечание и справедливо

Я сижу и туплю и не могу понять какая там асимптотика :/

но даже если перебираются не все возможные варианты, то большое количество

это отвечая на твой первый вопрос про то, будет ли оптимайзер джойнить А и С - вполне себе будет

Я сижу и туплю и не могу понять какая там асимптотика :/

асимптотика в плане количества вариантов? в http://www.benjaminnevarez.com/2010/06/optimizing-join-orders как раз указано

Всем привет. Кто может посоветовать либу websocket для haskell?

websockets?

Так и называеться?

https://hackage.haskell.org/package/websockets https://hackage.haskell.org/package/wai-websockets

А то вроде немного погиграться рикрутил web socket вместо очереди. Хочу просто на другом языкке сервачок небольшой написать.

Зечем websocket вместо очереди, если можно просто socket взять?

Ну можно. Но тогда можно быдет быстро веб интрерфейс прикрутить.

И в java spring web socket в 20 строчек поднимаеться с маппингом и прочими плюшками. А для server socket нормальной поддержки нет.

Хотя если нагрузка начнет расти, то возможно пидеться смотреть в стророну netty:)

@volhovm у вас в universum случаем нету join . atomically . asum а если есть, то как обозвали?

а то у нас достаточно часто встречается такой паттерн, а как обозвать непонятно

@qnikst Такого случайно нет. atomically — это из STM? Не знаю, встречается ли у нас часто такой паттерн...

да

это когда есть stm, который возвращает какой-нить IO, который выполнить

да = из STM

А что делает asum в данном случае?

выбирает из транзакций

asum [stmAction1, stmAction2, ..]

оно работает как stmAction1 orElse stmAction2 orElse retry

можно конечно asum не втаскивать и только join atomically оставить

@qnikst а что есть universum в данном случае?

очередное prelude/base done right

(это не пренебрежительный комментарий был если что)

> Reimagined approach for Foldable type hierarchy. Forbids usages of length function and similar over Maybe and other potentially unsafe data types. It was proposed to use -XTypeApplication for such cases. But this approach is not robust enough because programmers are human and can easily forget to do this. ясно понятно

class Container t => NontrivialContainer t

обозвал runSTM и runSTMs

кстати, никто не в курсе, чего lts-стакана под 8.2 так всё и нету?

Там баги :) Мы попробовали на Nightly с 8.2.1 пересесть, теперь вот расхлёбываем - пишем багрепорты, вот это всё

Баги компилера

что, больше, чем обычно в .1 ?

Достаточно одного, но блокирующего

ну т.е. как обычно

у нас пока что попалось - неблокирующее

@astynax а что там такого страшного в этот раз? В .2 RC1 еще есть?

сам-то я и не пробовал еще на 8.2 переходить

Shadowed dependencies на пустом месте ещё выпадают?

мы в RecordWildcards на что-то наткнулись

или чем-то близком

RecordWildcards урезали же

Shadowed dependencies на пустом месте ещё выпадают?

Это да, точечный clean временно помогает

RecordWildcards урезали же

что там урезали?

захват на топлевеле точно урезали, может еще что

https://ghc.haskell.org/trac/ghc/ticket/14347

ну я это не юзал, больше в функциях, чтобы не париться с PM

I don't think anyone is using record wildcards in this bizarre way, so I don't expect any fallout.

ЕМНИП Леннарт говорил, что использование для энкодинга модулей у этой фичи штатное

но то, что эту фичу так и не стали в таком качестве использовать - это факт, конечно

хотя ее переодически "открывают", Гонзалес сколько-то лет назад, а недавно вот и SPJ

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

Check out @crazy_fizruk’s Tweet: https://twitter.com/crazy_fizruk/status/918868614257762304?s=09

Check out @skillsmatter’s Tweet: https://twitter.com/skillsmatter/status/918833954718912512?s=09

Алкоголики! Тунеядцы!