(defn to-num1 [seq-nums] (apply + (map * seq-nums (iterate (partial * 10) 1))))
 (defn to-num2 [seq-nums] (reduce-kv #(+ % (* %3 (long (Math/pow 10 %2)))) 0 (into [] seq-nums)))

(time (map to-num1 (partition 3 (range 200000)))) => "Elapsed time: 0.063412 msecs"
(time (map to-num2 (partition 3 (range 200000)))) =>  "Elapsed time: 0.062708 msecs"

Для большого списка seq-nums первый вариант будет оптимальнее по памяти если apply заменить reduce. Если ничто не указывает на начало списка gc сможет подчищать реализованные элементы списка пока выполняетсч reduce.

Туше))

всем привет. кто пользуется мигратусом?
Хочу понять стратегию использования.

У нас в проекте, с помощью sql создаются:
1. Пользователи
2. База данных
3. схема. даются гранты на схему пользователям из п 1.
4. Создаются несколько таблиц и функции.

Соответственно вопросы:
1. пункты 1-3 должны быть в скрипте init.sql или в скриптах типа up & down?
2. каждую таблицу делать в отдельный файл ( up & down) ? или создание всех таблиц  можно запихать в один файл (up & down)

Сам потею над этим уже неделю, нихрена не понятно

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

Не могу сказать, что прямо много пользовался, но я бы 1-2 запихал в init.sql, остальное по вкусу.
С одной стороны, сколько таблиц добавляется — столько и добавлять, чтобы было консистентное состояние системы.
С другой стороны, если завалится миграция, то есть вероятность, что будет сложнее понять, что навернулось.

так он в ошибках напишет где завалился

Да, но ошибки тоже программисты писали

создание базы и системных пользователей лучше сделать в init, а наполнение базы в миграциях. В одном файле можно держать несколько таблиц. Это удобно, если они относятся к одной фиче.

например

;; up.sql

begin; 
create table foo ()...
create table bar()...
insert into foo...
insert into bar...
commit;

Спасибо всем. Буду пробовать

Спасибо=) опытным путем выяснил что все дело в вызове Math/pow, если заменить на самописный вариант, то тесты проходят

Когда самопал круче стандарта

Math/pow возводит float в степень float и судя по (long ) вокруг там ещё и боксинг/анбоксинг на каждой итерации.

;; down.sql
begin
drop table bar
drop table foo
commit;

Спросил на всякий случай еще у Димы Сотникова (автора мигратуса). Он тоже сказал, что 1-3 лучше разместить в init.sql.
Таблицы лучше разместить в скриптах up & down. Обычно он делает up & down per table (а не все в одну кучу). однако можно и в одну кучу, если это имеет место для всей схемы и добавляемых фич. То есть можно и так и так.
Еще он посоветовал вот эту тулзу https://github.com/leafclick/pgmig
Это standalone мигратор, который использует внутри мигратус, и применяется он в том случае, когда на изменение схемы у приложения нет прав. Тогда нужен предварительный deploy step с соответствующими правами. Правда этот тул только для Postgres.

Надеюсь будет для кого-нибудь полезная инфа.

Кто-нибудь сталкивался с тем, что reagent не ререндерит :i?

Примерно такой компонент:

(defn some-func [done]
  [:some-parent
   [:span (str n " " done)] ;; works here
   [:span.icon.is-small
    [:i {:class (if done icon-done icon-hover)}] ;; doesn't work here
    ]])

...[some-func @some-atom]

Пробовал заменять :i на :div - тоже работает.
[:div {:style {:background (if done "red" "blue")}} "some-text"]

Всё рендерит, смотри консоль

Может там что