• дыбр SQL Haskell погроммирование Прикольно, для yesod есть целых два "пагинатора": тыц hackage.haskell.org и тыц hackage.haskell.org

    Но это всё не то, когда речь заходит о рекурсивных запросах (CTE), которые тянут по JOIN по несколько сотен тысяч записей. Чувствую, быть ещё одному. Да, yesod-persistent и esqueleto мимо по той же причине. Запрос в итоге генерирую руками, поскольку планы запросов на первом месте: lpaste.net

Replies (33)

  • @agr, Если ты на постгре (я надеюсь) то вот тебе bitbucket.org
  • @agr, в тот момент когда я пользовался есодом, уже было 2 пагинатора, но оба бесконечно убогие, что я накостылял свой. Через полгода-год после этого один из них правда поумнел, что подошел бы для моих очень скромных нужд.
  • @segfault, Спасибо, взгляну подробнее.
  • @agr, Умеет в интерполяцию запросов аля [sqlExp|SELECT ^{fields} FROM ^{table} WHERE field = #{value} ^{limits}|] . Внутри все на байтобилдерах, так что эффективно даже.
  • @segfault, Хоть кто-то на SQL пишет на SQL а не на всяких персистентах и т.п.
  • @segfault, Документаша пока не готова, я ей завтра займусь, и оно требует форкнутого pgs вот отсюда github.com
  • @segfault, А по теме — оно может WITH RECURSIVE t(^{fields}) as (SELECT ^{fields} FROM ^{table} UNION ... ) ?
  • @agr, Да, и коменты вырежет, и пробелы лишние
  • @segfault, вообще крутотень, респект!
  • @agr, и можно даже `pgExecute $(sqlExpFile "products/yoba")` аля йесодотемплейты для скуль
  • @segfault, заембедит из файла
  • @agr, Будь готов что оно скоро будет ломаться, мы пока активно пилим ее
  • @segfault, ваще круто, а то в yesod-persistent ну вообще не по-русски сделано.
    * Без плэйсхолдеров (??) запрос работать нормально не может.
    * С плейсхолдерами — тоже не может, Entity никак не определить до тех пор, пока WITH ... не обернёшь в подзапрос с алиасом той сущности (template — в моём запросе по ссылке), из которой надо извлечь данные.
  • @segfault, Документашку бы. Алсо битбакет хипстеры.
  • @segfault, подпишусь, понаблюдаю до стабильного релиза, пока попридержу коней, раз такое дело.
  • @rufuse, Зато мы от блокировок недавно не страдали, как некоторые trollface.jpg
  • @agr, Сильно меняться оно уже точно не будет, разве что компилируемость иногда будет ломаться. Мы планируем переименовать это в более понятный `postgresql-query`
  • @agr, Если правильно понял о чём речь в запросе: нужно выбрать все товары из всех категорий потомков. В связи с чем тупой вопрос. А почему нельзя отделить категории от связей родитель-поток, запихнуть связи в отдельное отношение и добавить в него транзитивные отношения между категориями? Опционально с хранением уровня отношений.
  • @inglorion, В целом, да.
    1. Не "товары", а "Х" — там много чего помимо товаров.
    2. Можно и даже нужно так сделать. Во сне обсчитывал варианты. Дешевле выйдет рекурсивный запрос родительских категорий для вставки в референсную таблицу с Х. А выборка из неё также дешевле рекурсивного запроса.
  • @agr, каждый раз когда я вижу про дерево и рекурсию ради него, то я спрашиваю: почему не flat tree? {id, left, right,...}?
  • @qnikst, (В SQL естественно). У этой штуки дорогая вставка и дешёвые поиск, выдача поддерева, (выдача "наддерева") проверка на то является ли листом.
  • @qnikst, Потому что сходу не придумал, всё же на коленке пишется.
    Использовал типичную тему вида (id, parent_id). На сервере строю дерево. Думал юзать деревья, да, но сходу не разобрался, как их разворачивать на сервере и передавать клиенту.
  • @agr, Вот эта штука выше это из SQL серверов для бедных, не умевших в рекурсию, я видел такое в бытность пхп-шником, однако интересно, что уданной структуры очень интересные свойства, правда модификация дорогая вставка O(N) в лучшем случае (мне не сообразить сейчас).
  • @qnikst, Это ж говёная структура для хранения деревьев: добавление одного элемента заставляет пересчитать все связи в дереве, код под это писать неудобно. Почти всегда применяется только к деревьям игрушечного размера (помещается в память).

    Зато удобно одним запросом можно загнать все узлы дерева в массив в DFS порядке. Программисты на PHP с array головного мозга оценили эту фичу по достоинству: сами развернуть дерево в список они не в состоянии.
  • @inglorion, Я ж написал, что дорогая вставка, но очень дешевая выборка поддерева. Что именно нужно ТС я не знаю.
  • @qnikst, Дешевая выборка поддерева и при хранении транзитивных связей. Повторюсь: единственное преимущество flat-tree --- получение узлов в DFS порядке одним запросом без кода в приложении.
  • @qnikst,
    1. вставка — редкий кейс
    2. выбор поддерева, выбор наддерева
    3. выбор Х как в #2770694
  • @agr, flat-tree не умеет выбирать всех предков для узла.
  • @agr, /28 верно, под странным термином "наддерево" я имел ввиду или дерево включающее данное или хм.. Ту часть дерева, которая выше по иерархии и идет раньше при BFS обходе.. (Криво наверное объяснил)
  • @qnikst, Кстати, наддерево тоже достаточно просто выбирается, обратно, если правильно понял о чём речь. Для каждого узла помечается его глубина/уровень в дереве: наддеревом будут все узлы у которых уровень вложенности меньше.
  • @inglorion, если помнишь flat tree то я про left<node.left right>=node.left, left<node.right (если не туплю). Т.е. в дереве A [B, C [ N], D] если ищем для N то вернётся A [C N], но может я и туплю.
  • @qnikst, Ну да, если задать условие left < node.left and right >= node.right, то получится выбрать путь до узла. Как бы под это индекс построить?
  • @inglorion, Подозреваю, что в базах не умеющих в рекурсию — никак. Тогда когда я такими штуками пользовался особо не задумывался.