Назначение параметров minSupported и maxSupported в getVersion API - PullRequest
0 голосов
/ 13 февраля 2020

Я нахожу getVersion API немного трудным для gr asp. После некоторых ручных экспериментов с изменениями рабочего процесса я обнаружил, что прекрасно иметь такой кусок кода:

val version = Workflow.getVersion("change#1", 1, 1);
val anotherVersion = Workflow.getVersion("change#2", 2, 2);
  1. Означает ли это, что целочисленная версия назначена для changeId а не рабочий процесс? Сохраняет ли один экземпляр / выполнение рабочего процесса набор целочисленных версий?

  2. Для чего нужны параметры minSupported и maxSupported? Почему бы просто не использовать API, как показано ниже?

val version = Workflow.getVersion("change#1")
if (version) {
   // code after "change#1" changes
} else {
   // code before "#change#1" changes
}

1 Ответ

0 голосов
/ 13 февраля 2020
  1. Вы правы, версия назначена для changeId, а не для экземпляра рабочего процесса. Это позволяет управлять версиями каждого фрагмента кода рабочего процесса независимо. Это позволяет исправлять ошибки, когда рабочий процесс уже запущен и не достиг этой части кода.
  2. Основная причина - проверка. Записи getVersion в истории рабочего процесса maxVersion, когда код был выполнен в первый раз. Таким образом, при воспроизведении используется правильная версия, чтобы гарантировать правильное воспроизведение, даже если maxVersion изменился. Когда ветвь удалена, minVersion увеличивается. Представьте, что такой код разворачивается по ошибке, когда есть рабочий процесс, которому требуется удаленная ветвь. getVersion обнаружит, что minVersion больше, чем записанное в истории, и не выполнит задачу решения, по существу блокируя выполнение рабочего процесса, а не прерывая его. То же самое происходит, если записанная версия превышает аргумент maxVersion.

Обновление: ответ на комментарий

Другими словами, я пытаюсь прийти в ситуации, когда недостаточно использовать разные changeIds и не превышать maxVersion = 1

Их достаточно, если вы не выполняете удаление ветвей. Но если вы делаете, то проверка минимальной версии очень удобна. Например, посмотрите на следующий код:

val version = Workflow.getVersion("change", 0, 2);
if (version == DEFAULT_VERSION) {
   // before change
} else if (version == 1) {
   // first change
} else { 
   // second hange
}

Давайте удалим версию по умолчанию:

val version = Workflow.getVersion("change", 1, 2);
if (version == 1) {
   // first change
} else { 
   // second hange
}

Теперь посмотрим на версию без min и max:

var version1 = Workflow.getVersion("change1");
var version2 = Workflow.getVersion("change2");
if (version1 == DEFAULT_VERSION) {
   // before change
} else if (version2 == DEFAULT_VERSION) {
   // first change
} else { 
   // second hange
}

Давайте удалим ветвь по умолчанию:

var version2 = Workflow.getVersion("change2");
if (version2 == DEFAULT_VERSION) {
   // first change
} else { 
   // second hange
}

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...