Comment 3 for bug 1815710

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to mistral (master)

Reviewed: https://review.openstack.org/636548
Committed: https://git.openstack.org/cgit/openstack/mistral/commit/?id=a39db2d3dc21afbe8b9e1d6f8dd870da272b9671
Submitter: Zuul
Branch: master

commit a39db2d3dc21afbe8b9e1d6f8dd870da272b9671
Author: Renat Akhmerov <email address hidden>
Date: Wed Feb 13 12:36:49 2019 +0700

    Fix how Mistral prepares data for evaluating a YAQL expression

    * If we use the built-in YAQL function 'str' in a workflow then it
      doesn't represent lists as '[item1, item3, ...]' but instead
      creates '(item1, item2,...). This is because the standard YAQL
      function 'yaql_utils.convert_input_data', which is needed to
      convert a initial user data into an internal YAQL format,
      converts all sequences (except strings) into tuples.
      This patch overrides this behavior for sequences that are not
      strings and tuples so that they now get converted into lists.
      YAQL uses tuples because it needs to obtain a safe immutable
      structure to make calculations upon. But in Mistral list is
      more suitable because lots of users care about string
      representations. Immutability is not so important because
      Mistral code base guarantees that the initial data context
      for an expression won't be changed while an expression is
      being evaluated by YAQL.
    * "str" YAQL function used to work well but it was broken in
      https://review.openstack.org/#/c/477816/ that added additional
      context preparation in order to fix the issue
      https://bugs.launchpad.net/mistral/+bug/1772864

    Change-Id: I69d32f8772418d586d6c414842bb54aada217481
    Closes-Bug: #1815710