Clojure, ленивость и отложенные отчеты

[metaclass]

Очередной раз стукнулся об ленивость.

Делаю фоновый расчет отчетов - клиент просит у сервиса "посчитай мне отчет", тот ему возвращает идентификатор-ссылку на future со считалкой отчета и далее клиент опрашивает сервис на предмет "а не готов ли наш отчет" и тот ему отвечает либо "не готов" либо "готов, вот тебе данные".
Ну, склепал очередь отчетов - атом, в нем мап, в мапе идентификаторы запрошенных отчетов и future к ним. Запускаю - а оно мгновенно говорит, "да, вот отчет готов, забирай" и давай его считать и отдавать. В потоке запроса, не в рабочем потоке future.
Ленивость. Оно возвращает башку последовательности данных отчета сразу, "на тэбэ, дорогой, форси меня". И запрос готовых данных (в том числе, даже просто попытка в целях отладки посмотреть на мап с future) - вызывает форсинг последовательности.

PS: И еще обнаружил очередную фичу кложури - thread-local bindings протаскиваются во все вызовы, которые перекладывают работу в другие потоки. Т.е. конкретно тут - я в запросе часть общих параметров (типа имени пользователя) складываю в thread-local binding чтобы не протаскивать их руками через 100500 функций, думал, что при вычислении внутри future придется их доставать и перекладывать во второй поток - а оно уже сделано.
Авторы кложури не перестают удивлять своей крайней адекватностью и практичностью языка.

Comments

[sergiej.livejournal.com]

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

Резюмируя. Если бы нужно было написать один грид с пажинейшеном, и я бы видел что адекватный программер (вы например) за это берётся, я бы только сказал бы "делай". Но если надо сделать решение, которое универсально и любой условный "индус" (даром что не из Индии) может повторить/использовать. То я остаюсь при своём. В системах, с которыми я работаю - сотни гридов. И к сожалению нет во фреймворке готового решения для пажинейшна, вся эта дискуссия не праздна, меня задолбал зоопарк, который творят на каждой форме. В одном внедрении насчитал 5! разных форм работы с гридами (по количеству команд скорее всего). Я хочу сделать скроллинуемый "до бесконечности" (до тысячи но настраиваемо :) ) грид частью "общего" фреймворка.

[berezovsky.livejournal.com]

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

[metaclass.livejournal.com]

Да, меня это тоже удивляет.

[sergiej.livejournal.com]

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