kaliop-uk / ezmigrationbundle Goto Github PK

When attempting to update a content_type via the yml definition, I get the following error:

Migration aborted! Reason: Error in execution of step 1: Could not find 'eZ\Publish\SPI\Persistence\Content\Type' with identifier 'ID: featured_banner, Status: 0' in file /srv/www/www.ovumkc.com/vendor/ezsystems/ezpublish-kernel/eZ/Publish/Core/Persistence/Legacy/Content/Type/Handler.php line 251

The migration is attempting to update the identifier for the content_type itself, along with several attributes. The migration definition is as follows:

-
    mode: update
    type: content_type
    identifier: featured_banner
    new_identifier: front_page_banner
    attributes:
        -
            identifier: featured_banner_title
            new_identifier: title
            name: Title
        -
            identifier: featured_banner_image
            new_identifier: background_image
            name: Background Image
            description: Image used for background of the banner

1. when passing in some paths, limit list of executed migrations displayed to those which match the path
2. add a summary section, just like doctrine migrations

As this has happened in eZ5 a while ago

According to the documentation, binary files should be placed in MigrationVersions/files/, and paths to these files should be relative. However, this generates the following error:

Migration aborted! Reason: Error in execution of step 1: Argument '$value->inputUri' is invalid: 'data_and_forecast_catalogue.xlsx' is wrong value in class 'eZ\Publish\Core\FieldType\BinaryFile\Type' in file /srv/www/www.ovumkc.com/vendor/ezsystems/ezpublish-kernel/eZ/Publish/Core/FieldType/BinaryBase/Type.php line 97

Setting the full path from / does work.

You can only go so far before manual validation becomes a mess...

nuff said

So that the migration file does not have to be renamed after the fact

On eZ Platform adding new policies to existing roles fail with the following error message:

Error "Argument 'module' is invalid: 'NULL' is wrong value in class 'PolicyCreateStruct'"

-
  mode: update
  type: role
  name: Editor
  policies:
    add:
      -
        module: content
        function: create
        limitation:
          -
            type: ParentClass
            value: [1, 42]
          -
            type: Class
            value: [reference:contentTypeId1, reference:contentTypeId2, reference:contentTypeId3]

Hello,

On a standard eZ Platform and eZ Studio install with the demo content trying to remove the image attribute from the Article content type the migration exits with the following error:

Error "At least one element is required as value."

All other attributes can be removed without any issues.

Content of the migration yml file.

 -
    mode: update
    type: content_type
    identifier: article
    remove_attributes: ["image"]

If you need any more info please let me know.

enough said...

Both are useful enhancements

In short: we could do a full ezp db dump, doing a breadth-first descent and making sure that user accounts are dumped 1st and contents 2nd.

What would be missing is the handling of object relations: since in ezp relations can be circular, the import should allow creating content even with broken object-relations, and do multiple passes to fix those after all contents have been created.

Note: this most likely depends on issues #34 and #46.

At the moment the process to inject the parsing of custom references is quite long and error prone.
Having it work via tagged services would make it easier to extend the bundle...

This makes it easy to execute separate migrations which deal with the same set of objects.

Currently, it is possible only as long as the separate migrations are executed within the same 'migrate' command.

• option 1: allow migrations to fail, create 3 migrations => workaround, notperfect
• option 2: use v2 config format, set references as part of the 'configuration' section, based on sf env => better :-)

so that we can run the tests

With out being able to get a subtree path reference for created content you cannot assign a role to a user with a subtree limitation to the created content.

It would be nice if the extension provided some kind of 'lorem ipusm' functionality.

For that, it would need, at a minimum to:

• support for content creation a 'repeat' tag
• have a reference resolver which generates random text (and do late-binding for its values)

Queued for v2 of yml spec

Title says it all.

This would make the extension a fully capable of content export - import

Look for usage of getParameter

The codebase and the status command now support it, but not the generation one.

We could f.e. look for th presence of the / char in the 1st argument to tell apart bundles from paths...

So that devs extending this dont have to mess around with the definition of the ez_migration_bundle.complex.field.manager service

since there are repository services for that, why not...

it seems a bit confused right now...

The problem is due to the fact that db changes done by the migration executor are wrapped in a transaction, and that in 2014.3 the legacy stack uses a separate database connection from the ez5 stack.

The result is that, when content is created via a migration, the legacy stack tries to send it to the indexation engine, but fails because it does not 'see' the content at all in the database.

A possible fix would be to disable usage of transactions completely, but that would introduce more problems than it solves.

Another fix could involve setting up a custom signal listener which would do the db commit before firing the legacy indexation code...

...or we could stop supporting 2014.3 altogether, as it is slightly buggy and will most likely not see any fixes in the future

Top-level elements might become:

• version
• configuration
• steps

This will allow for far greater flexibility

instead of hardcoding them in a command

Suppose you are working in a bundle with 20 or 200 yml definitions. it would be good to have a way to retry just one of them. Maybe passing the name of the file as argument to the command?

at least allow one to be passed in via the cli;
maybe allow defining the user id in the yml ?

A bit of docs could go a long way

The 'matcher' concept should be extended as well to users (match by email, login), user-groups, content-types, roles, locations

At the moment too much logic is in the command, this makes it duplicate and hard to reuse/share

advantage: make it easy to support many dialects in 1 file

Reference resolvers could be made much more generic:

each reference should follow a syntax: what_to_get/how_to_match

ex:
location.id/by/location.remote_id/eq/abc
location.remote_id/by/location.id/eq/23

While this is verbose, it is flexible enough to be used everywhere in the migrations definitions.

Apart from content and location, we can use resolvers to identify users, user_groups, roles, netgen tags, etc...

The core 'fetch' code can be kept in the matchers classes, with resolvers making sure that there is only 1 match, and that the correct attribute is returned.

The main question is: what is the better syntax to use for defining such references?
a - follow the KISS principle
b - make it instead similar to css selectors / xpath selectors

It would be great if we could run a specific migration file without tracking it. This would be handy as a migration could be used as a template or 'import' to add a site structure for example to the repository that does not need to be tracked.

This makes updates easier to write than merely adding a list of IDs as an array

Eg: update attribute X to value Y of all locations which are child of node Z and have attribute W set to value K

Hi there. Nice bundle :).

Actually, as far i can see, it seems you can define two types of migrations, yaml and sql.
What about another one that will allow execute custom php code, maybe a symfony command?

Could be useful, for example, for people wanting to delete, hide or move a bunch of contents...

Thoughts?

It seems that this might be a Travis bug rather than in code, but anyway:

currently the test suite fails on php 7 because eZPlatform config files in yml format do have unquoted string values starting with '@'. Normally this is not a fatal error in Symfony 2.8 (the version which gets installed along the current eZPlatform version), only in 3.0. Also, the error message mentions line numbers which correspond to Sf 3 sources.
As such, the error thrown does not seem to make any sense. It might come from some caches, or Composer getting confused ?

Not often used, I guess, but could do with creation/removal of languages...

When trying to update a content object that has an ezrichttext field with xml that worked with ezxmlfield in the past I get an exception:

Error "Could not find 'Validator' with identifier 'NULL'"

This is on a standard eZ Platform/eZ Studio install with demo content.

To be done as part of v3 file format

as name is hardcoded in creation sql

In the current dsl, it is not clear which attributes are used to identify, and which ones are part of the update

This makes it hard to create migrations which update the remote id, as well as allowing identification of objects by their name or other attribute (we might even extend the API to mass-update contents if we allow selectors to return not-only-one node/location)

Currently, a value/id which can be set to be a reference is scanned for presence of the substring 'reference:' anywhere

1. it should only match if the substring is present at position 0
2. we should probably allow that substring to become a config parameter
3. we could possibly use regexps to validate/extract references...

• top-level distinction should be between Core and API
• use only singular nouns for namespace parts
• do we need to keep the suffix in class names when the namespace already contains it ?

We can take the code from https://github.com/inviqa/ezmigrationbundle

Right now everything is hardcoded...

The easiest and most useful way to make sure there are no breackages is to have a folder full of yaml files with migrations, and have phpunit execute the Sf commands that run them

Common scenario:

• add a new Doctrine ORM entity via code + annotations
• want to have the sql for creating the table added to your migrations

It is not too hard to do, but not very documented.

In fact, we could even add a one-liner for that...