metaclass: (Default)
Firebird и лямбда-функции, часть 3:
Я таки спросил про функциональное программирование, и к чему это привело:


>> т.е. если оно не исчезнет через год-два-три, возможно посмотрю пристальнее.
> ну в высоконагруженных сильнопараллельных программах оно существует уже не год-три, Erlang и написанные под его влиянием
> библиотеки.
Я не собираюсь продолжать эту беседу ибо она была спровоцированна с единственной целью - поржать в ЖЖ над частично процитированным и оторванным от контекста моим частным мнением. Выставляя косным идиотом не только меня (на это мне наплевать), но и Firebird вместе со всем его сообществом.


Короче, не выходит у меня дискуссия на тему "как скрестить базы данных и функциональное программирование". Все уперлось опять в то, что я не пресекаю критику Firebird и его сообщества у себя в ЖЖ. Есть какой-то элемент сектанства в сообществе, мешающий объективно и без эмоций воспринимать критику. Ладно бы еще я призывал всех на другие СУБД переходить - понятно, конкуренция типа. Да и то это без эмоций разруливать удобнее.
metaclass: (Default)
«Штирлиц бежал по Цветочной улице, а Плейшнеры все падали и падали»

Народ срется наобсуждает вечную тему - реализация синхронизации/репликации содержимого баз, применительно к Firebird. Вообще говоря, существуют готовые решения для такого, но, насколько я помню, любое подобное решение в итоге накладывает какие-то не совсем вменяемые ограничения на дизайн базы.
В принципе, мне это тоже предстоит реализовывать, но по той причине, что основную обезъянью работу за меня будет делать кодогенератор, меня больше волнуют теоретические и высокоуровненые аспекты, а думать я над ними сейчас не в состоянии. Скорее всего, сделаю составной ключ "ID базы, ID записи".
metaclass: (Default)
Домудрился с вложенными ленивыми секвенсами вперемежку с обращениями к БД до такой степени, что сломал компилятор F#, похоже. Во всяком случае, он у меня теперь умудряется сделать Dispose команде доступа к БД до того как начнет генерить последовательность из нее. Причем, что удивительно - не всегда, а только при определенном паттерне обращения к другим командам.

Read more... )

Однозначно, что ленивость+внешние ресурсы это не совсем то, что следует делать, да и отладке это не подлежит в принципе, ибо монады. Но как превратить это дело в fold-like алгоритм, хрен его знает, да еще с учетом того, что там внутри не просто итератор по плоским записям, а внутри этих записей еще вложенные итераторы, а из них ссылки на элементы из других итераторов, в общем, ад тот еще.
Вот еще смех будет, если это не в F# проблема, а в ADO.NET провайдере Firebird.

PS: Судя по всему, все хорошо и пень все таки я - таки ленивые вложенные итераторы можно использовать только вложенно, а не так как я - сначала пройтись по внешнему, найти нужную запись, а потом из нее читать вложенные. Адекватный вариант - сделать их неленивыми. Обычно в этом помогает Seq.cache, но тут он, похоже, тоже вызывается в неподходящий момент.

PPS: Ухуху, и решение в этом случае действительно, как и советуют гуру ленивости - перевернуть все в fold-like алгоритм, передав две функции - одну для fold внешнего итератора и одну для fold внутреннего (и вроде в общем случае, еще две - одну которая будет из внешнего итератора и состояния делать начальное состояние для fold внутреннего, и вторая будет комбинировать результат от fold внутреннего итератора и состояние внешнего).
Это получается, что для fold в случае вложенных итераторов количество передаваемых параметров-функций прилично возрастает: по одной функции на каждый итератор в иерархии и +2 на каждый случай вложенного итератора, причем у самих этих функций количество передаваемых в них параметров тоже особой радости не доставляет.
Зато соответствующим набором таких функций, судя по всему, можно вычислить произвольную функцию от базы данных, представленной в виде набора разнообразно вложенных итераторов :)

Profile

metaclass: (Default)
metaclass

April 2017

S M T W T F S
      1
2345678
9101112 131415
16171819202122
23242526272829
30      

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 19th, 2017 11:34 am
Powered by Dreamwidth Studios