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

[metaclass]

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

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

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

Comments

[jakobz.livejournal.com]

Вообще мой поинт не в том, как правильнее делать. Я оба варианта юзал. Я даже делал грид с гибридным вариантом, там вообще прикольно получилось. Типа датасорсу говорят "дай мне минимум 20 строк", а он может вернуть просто больше, а может вернуть все вообще и поставить про это галку. А UI потом от этого пляшет у себя - ходить ему на сервак за новыми порциями, или нет. Фильтрация, сортировка и пейджинг независимо переключались между клиентским и серверным режимом.

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

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

[sergiej.livejournal.com]

"Потому что листать страницы - реально последняя мера для юзера, после того как не получилось отсечь все нужное поиском и вывести так, чтобы все было перед глазами на одном экране. "
да забудьте про ЖЖшки и вконтактики. В реальных бизнес задачах реального энтерпрайза якобы "реально последняя мера для юзера" это очень частая задача. Приведу пример ещё один, надо мне распечатать отчёт на 20 страниц. Но предварительно проверить не попал ли туда бред случайно. Если я посмотрю только на первую страницу это будет ок? Или мне все 20 страниц одним списком показывать и пусть скроллят?
Я даже хуже скажу, предвижу что с развитием "пальцевых" интерфейсов проблема консистентного пейджинга станет ещё более остро, тот бардак и индусятина которая позволяется сегодня не выдержит проверки временем. ТАкое моё ИМХО.
А сделать догрузку "новых" результатов в конце списка другим цветом (а в процессе перелистывания зажечь звёздочку что появились новые) это тоже легко и просто с моим механизмом.