Почистване на състоянието
Докато работният процес преминава през много стъпки, натрупаното състояние може да стане голямо. Автоматичното почистване на състоянието премахва резултатите от старите стъпки, за да поддържа размера му JSON в зададени граници и същевременно да запази важните данни.
Активиране на почистването на състоянието
Извикайте prune_state_after() върху създателя на работния процес. Аргументът е броят на последните стъпки, чиито резултати трябва да се запазят:
use Queuety\Queuety;
Queuety::workflow( 'long_pipeline' )
->then( StepA::class )
->then( StepB::class )
->then( StepC::class )
->then( StepD::class )
->then( StepE::class )
->prune_state_after( 2 )
->dispatch( [ 'input' => $data ] );
При prune_state_after( 2 ), след като стъпка D завърши, резултатите от стъпки A и B се премахват от състоянието. Стъпки C и D (последните две) се запазват.
Как работи почистването
Когато почистването на състоянието е включено, Queuety следи кои ключове добавя всяка стъпка към състоянието в запазен масив _step_outputs. След преминаване към нова стъпка се премахват всички ключове, добавени от стъпки, по-стари от зададения праг.
Например при prune_state_after( 2 ):
After step 0 (StepA): state has keys from StepA + initial payload
After step 1 (StepB): state has keys from StepA + StepB + initial payload
After step 2 (StepC): state has keys from StepA + StepB + StepC + initial payload
-> prune: StepA output removed (only 2 most recent kept)
After step 3 (StepD): state has keys from StepB + StepC + StepD + initial payload
-> prune: StepB output removed
Какво се запазва
Queuety никога не почиства запазени ключове, започващи с _, като _steps, _queue, _priority, _max_attempts, _on_cancel, _prune_state_after и _step_outputs. Ключовете от първоначалния полезен товар, подадени към dispatch(), също се запазват, защото изобщо не се проследяват като резултати от стъпки. Освен това Queuety запазва N-те най-скорошни резултата от стъпки според зададения праг.
Кога да го използвате
Почистването на състоянието е полезно за работни процеси с много стъпки, при които всяка стъпка създава данни, от които следващите стъпки всъщност не се нуждаят. Типични примери са дълги конвейери, в които всяка стъпка се нуждае само от резултатите от една или две предходни стъпки, ETL работни процеси, които генерират обемисти междинни структури, и рекурсивни или повтарящи се работни процеси, които иначе биха натрупвали повтарящо се състояние. Ако работният ви процес има само няколко стъпки или късните стъпки все още зависят от ранните резултати, вероятно изобщо нямате нужда от почистване.
Поведение по подразбиране
Почистването на състоянието е изключено по подразбиране. Методът prune_state_after() приема целочислен аргумент. Ако го извикате без аргумент, стойността по подразбиране е 2:
->prune_state_after() // keeps the 2 most recent step outputs
->prune_state_after( 5 ) // keeps the 5 most recent step outputs