Skip to content

Latest commit

 

History

History
executable file
·
117 lines (73 loc) · 8.25 KB

README.old.md

File metadata and controls

executable file
·
117 lines (73 loc) · 8.25 KB

#Цель: библиотека для повторного использования кода и упрощенного тестировани. по сути не отличается от обычного модульного программирования. основное преимущество, можно комбинировать код простым добавлением новых видов stage/pipline и их последующее использование в процессе работы.

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

  • дополнительные стандартные stage условный переход

  • возможность возврата на любой шаг вперед и назад

  • возможность задать следующий шаг

  • операции типа split combine для параллельного выполнения и задания точек синхронизации (типа сети петри)

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

  • возможность сериализовать структуру stage в файл.

  • останавливать выполнение stage (workflow);

#Требования к параллельному и к последовательному испольнению

  1. последовательно:
    • последовательно обработать массив конекстов.
    • stage который выполнит по

это специальный тип pipeline.

##Sequential

Stage с параметрами:

  • stage - Stage который будет выполняться внутри.

  • fork - процедура процедура которая делает fork текущего context-а для stage, или создает новый, может быть и на основен текущего, в зависимости от необходимости, и заполняет его специфичными данными.

  • reachEnd - условие завершения последовательности.

  • combine - метод который будет формировать результирующий контекст.

##Parallel c parallel все немного сложнее... проблема в том, что нужно будет предварительно создать все котексты и запустить из обработку... поэтмоу, возможно, в нем нет необходимости. НО!

  • stage - Stage который будет выполняться внутри.

  • fork - процедура процедура, которая сформирует массив конектстов, которые должны будут выполниться параллельно. Работает на основе fork текущего context-а для stage, или создает новый, может быть и на основен текущего, в зависимости от необходимости, и заполняет его специфичными данными.

  • combine - метод который будет формировать результирующий контекст.

##IFELSE

Stage с параметрами

  • condition - функция, которая на основании текущего контекта вычисляет условие.

  • succeess - Stage, который выполняется в случае condition(ctx) = true;

  • failed - , который выполняется в случае condition(ctx) = false;

#SWITCH

Stage с параметрами

  • condition - функция определяет строку для выборки условия.

  • cases - пары {значение:Stage}

  • defaults - ни один из перечисленных

обработка ошибок:

все последовательные операции обрываются после первой ошибки. все параллельные операции выполняются до конца, и ошибки суммируются.

записывать путь, который прошел контекст по конвееру - лог. чтобы было видно как и где и что.

https://twitter.com/NodeDublin/status/301307831133540352?uid=75756871&iid=fd641cec-8801-44b6-95fc-ff116de470a6&nid=12+595+20130212 может быть использовать stream? или что-то такое https://github.com/substack/stream-handbook, это позволит уйти от callback и вывести управление ошибками отдельно... скорее всего у меня все готово для этого... может быть придется чего то менять...

unwind делает сплит по всем вложенным полям объекта.

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

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

подумать стоит ли загружать объекты связи.... соменваюсь.

с новой транзакцией можно задавать механизмы для сохранения объектов и прочее.

и следует поменять машину состояний или вообще убрать...

контекст надо оборачивать вокруг класса. создавая для него проперти. тогда для некоторых вещей не надо будет делать обращения через getParent()

сделать версию для browser

TODO: 1. Timeout если код все же выполнился, какой-то метод придумать чтобы он мог быть вызыван Promises/A+ mpromise этот проще. q навороченный но... тяжелый... и не нужно так много... написать тесты на промисы.... 2. сделать подробное описание MWS сделать милисекунды в контексте https://nodejs.org/api/process.html#process_process_hrtime Context... посмотреть может быть сделать Wrapper вокруг контекста.... тогда все свойства брать через .get() !!!schema теперь обрабатывает ошибки... можно смело использовать для валидации и в начале и в конце... 3. Context сделать изменяемым через методы, а не напрямую... как это сделано в mongoose, и вообще посмотреть как это можно убрать.... или действительно делать wrapper не хочеться чтобы из за этого тормозило.