Skip to content

5.13.0
Compare
Choose a tag to compare
@gggeek gggeek released this 09 Nov 13:36
· 143 commits to master since this release
5.13.0
faca342

The number of new features, improvements and bug fixes in this release is probably the biggest this project has seen in a "minor" version so far; there just happens to be no "major" changes that warrant a bump in the major version number.
The 'developer experience' has been the primary focus of attention, along with test coverage.
Besides suggesting that everybody upgrade to the latest release, I recommend to read carefully the release notes, as long as boring as those might seem...

  • Improved: a single value for a content field of type ezcountry can be specified as a string instead of an array (issue #190)

  • New: taught the kaliop:migration:status command to sort migrations by execution date using --sort-by (issue #224)

  • New: taught the kaliop:migration:migrate command a new option: --set-reference (issue #162). This is allows to inject any desired reference value into the migrations.

  • New: taught the kaliop:migration:resume command the same new option: --set-reference

  • Improved: references can now be set using a simplified syntax. eg:

        -
        type: content_type
        mode: load
        match:
                identifier: philosophers_stone
        references:
            my_ref_name: content_type_id

    Note that you still need to use the old syntax for reference creation in order to be able specify overwrite: true

  • New: taught the reference/set migration step to resolve environment variables besides Symfony parameters (issue #199).
    Eg:

      -
      type: reference
      mode: set
      identifier: myReference
      value: '%env(PWD)%'

  • New: : taught the reference/set migration step not to resolve environment variables at all, eg:

      -
      type: reference
      mode: set
      identifier: a_funny_string
      value: 'reference:or_not_to_reference'
      resolve_references: false

  • New: taught the SQL migration step, when specified in yaml format, to resolve references embedded in the sql statement (issue #199), eg:

      -
      type: sql
      resolve_references: true
      mysql: "UPDATE emp SET job='sailor' WHERE ename='[reference:example_reference]'"

  • New migration step: sql/query, which can be used to run SELECT queries on the database (issue #199). Unlike the existing sql/exec step (previously known simply as sql), this step allows to set reference values with the selected data. Ex:

        -
        type: sql
        mode: query
        mysql: "SELECT login FROM ezuser WHERE email like '%@ez.no'"
        expect: any
        references:
            -
                identifier: users_count
                attribute: count
            -   identifier: users_login
                attribute: results.login

    For more details, see the complete specification in file SQL.yml

  • New migration steps: content_type_group/load and trash/load

  • New migration step: migration/fail, which is similar to migration/cancel, but leaves the migration marked as failed instead of executed

  • New: migration step proces/run now supports element fail_on_error, which triggers a migration failure if the external process executed returns a non zero exit code (issue #234)

  • New: all load/update/delete steps, as well as a couple non-repository-related steps, support the optional expect element. This is used to validate the number of matched items, as well as altering the value of the references created.

    • use expect: one to enforce matching of exactly one element, and set scalar values to references
    • use expect: any to allow steps matching of any number of elements, and set array values to references
    • use expect: many to enforce matching of one or more elements, and set array values to references
    • using expect enforces validation of the number of matched elements regardless of the fact that there are any reference definitions in the step, whereas references_type and references_allow_empty only activated if there was at least one reference defined
    • also, the validation of the number of matched elements, when required, now happens before any item deletion/update action takes place. Up until now, for update steps, only a subset of the validation was enforced before the action, and the rest was validated afterwards

  • Improved: using the not element in matching clauses would not work for most types of steps, when the element not-to-be-matched was not present in the repository. Notable exceptions being Content and Locations matches.
    This case now works.
    Example of a migration that would fail: find all content types except the one 'philosophers_stone'

        -
        type: content_type
        mode: load
        match:
            not:
                identifier: philosophers_stone

  • New: most load/update/delete steps support the optional match_tolerate_misses element (issue #235).
    When setting it to true, the migration will not abort if there are no items in the repository matching the specified conditions.
    Example of a migration that would previously always fail: update non-existing content type 'philosophers_stone'

        -
        type: content_type
        mode: update
        match:
                identifier: philosophers_stone
        # make this step successful in case we have not found the stone yet...
        match_tolerate_misses: true

  • Fixed: setting references using jmespath syntax in migration steps migration_definition/generate

  • BC change: when matching users by email in steps user/update, user/delete, user/load the migration will now be halted if there is no matching user found. This can be worked around by usage of match_tolerate_misses: true

  • Improved: step reference/dump will not echo anything to stdout any more in case the migrate command is run with -q

  • Improved: when generating migrations for Role creation/update, the bundle now tries harder to sort the Role Policies in a consistent way, which should make it easier to diff two Role definitions and spot changes

  • Improved: made console command kaliop:migration:migrate survive the case of migrations registered in the database as 'to do' but without a definition file on disk anymore - a warning message is echoed before other migrations are run in this case

  • Improved: made console command kaliop:migration:migrate -vv more verbose than kaliop:migration:migrate -v.
    Besides printing one message before each step begins execution, it also displays time taken and memory used for each step (issue #200).
    Also, improved the output of kaliop:migration:migrate -v by printing step numbers

  • New: migration steps can now take advantage of $context['output] to echo debug/warning messages (issue #201).
    When set, it is set to an OutputInterface object.

  • Improved: many new and improved test cases

  • New: taught the test-execution command teststack.sh two new actions: console and dbconsole, as well as a few new options: -r runtests, cleanup ez-cache and cleanup ez-logs. It also accepts the name of a testcase to be run instead of the whole suite and other phpunti command line options, when executing runtests.

  • Fixed: regressions when running the test-execution command teststack.sh with the -u option or resetdb action

  • BC change: some options for the test-execution command teststack.sh have been renamed, see teststack.sh -h for the new list

  • BC change: the references_type and references_allow_empty step elements have been replaced by a new element: expect.
    The references_type and references_allow_empty step elements are still handled correctly, but considered deprecated; equivalence matrix:
    expect: one <==> references_type not set or equal to scalar
    expect: any <==> references_type: array and references_allow_empty: true
    expect: many <==> references_type: array and references_allow_empty not set or equal to false
    For developers: the RepositoryExecutor class and its subclasses have dropped/changed methods that deal with setting
    references. You will have to adapt your code if you had subclassed any of them

  • BC change: the database tables used by the bundle are now created by default with charset utf8mb4 and collation utf8mb4_general_ci (issue #176). They used to default to utf8 and utf8_unicode_ci.
    This is in general not a big issue, as there are no queries with joins between our tables and the eZP ones, but in case you have custom code that does those queries, those might fail if the charset or collation differ.
    To fix that, you can set different values to the Symfony parameters ez_migration_bundle.database_charset and ez_migration_bundle.database_collation.
    Note that this 'change' only applies to new installations of the bundle - if the migration tables already existed in your database before upgrading to the latest Migration Bundle version, they will not be modified.

  • BC change: some cases of \InvalidArgumentException being thrown have been replaced with Kaliop\eZMigrationBundle\API\Exception\InvalidStepDefinitionException

Assets 2
Loading