Allow executions of migrations in separate processes

For when you have a lot of migrations and memory leaks ;-)

New features galore!!! (and a tiny pinch of BC breackage)

• New: updating and deleting of Users, User Groups, Roles and Content Types now accepts more flexible definitions of the elements to act upon, and comprehensive resolution of references
• New: it is now possible to assign a section when creating and updating Contents
• New: it is now possible to assign an owner when creating and updating Contents
• New: it is now possible to set publication and modification dates when creating and updating Contents
• New: it is now possible to assign object states when creating and updating Contents
• New: it is now possible to assign a remote id for the Location when creating Contents
• New: references are now resolved for user_id and group_id when assigning Roles
• New: the main_location and other_locations tags in Content creation, as well as parent_location in Location creation will now try to identify the desired Location by its remote id when a non integer value is used
• New: the content_type_group tags in ContentType creation will accept a Content Type Group identifier besides an id
• New: added 2 events to which you can listen to implement custom logic just-before and just-after migration steps are executed:
  • ez_migration.before_execution => listeners receive a BeforeStepExecutionEvent event instance
  • ez_migration.step_executed => listeners receive a StepExecutedEvent event instance
• Fixed: migrations will not silently swallow any more errors when creating users or assigning roles and an inexisting group is specified
• New: it is now possible to add resolvers for custom references using tagged services. The tag to use is: ez_migration_bundle.reference_resolver.customreference. For an example, see the test UnitTestOK010_customrefs.yml and class Kaliop\eZMigrationBundle\Tests\helper\CustomReferenceResolver
• New: it is now possible to inject field type handlers for scalar field types, as well as for field type handlers that only affect the field type of a single content type. This gives greater flexibility in deciding which types of references are resolved for each field when creating or updating contents
• Changed: removed unused Behat and Phpunit tests as well as one leftover Interface
• Changed: removed from the YML documentation the description of keys which had been deprecated in version 2. The keys are still accepted, but support for them will be dropped in a future version
• Changed: the service ez_migration_bundle.reference_resolver.content is now deprecated and will be removed in a future version
• Changes to the YML definition language:
  • Updating and deleting of Users, User Groups, Roles and Content Types: usage of a match key is allowed; previous ways of defining elements to match are deprecated
  • new tags modification_date, section, object_states and owner are available for content creation and update
  • content creation supports the following new tags: is_hidden, sort_field, sort_order, location_remote_id
  • content update supports the following new tags: creation_date
  • location creation and update now support the tag parent_location as preferred form for parent_location_id. The former variant is considered deprecated and will be desupported in a future version
• BC BREAKS:
  • when deleting users, a single migration step can not be used any more to match users based at the same time on id, email and login. Use separate steps for that
  • when creating an object and defining its remote_id, the location remote_id is not automatically set any more. On the other hand, it is possible to set the location remote id explicitly using tag location_remote_id
  • when adding locations without defining sort field and sort order, the defaults from the content type definition are used, instead of publication-date/asc
  • references to 'tag:' and 'location:' will not be resolved any more in fields of type Object Relation and Object Relation List. On the other hand non-integer strings will be resolved as remote-content-ids
  • changes for developers who extended the bundle: the MatcherInterface and ReferenceResolverInterface have a new method each; many Executor services now have a different constructor signature; one Trait has been removed from the public API; the service ez_migration_bundle.helper.role_handler has been renamed to ez_migration_bundle.helper.limitation_converter; the chainResolver will now apply reference transformation from all matching sub-resolvers, not only from the 1st one

Bugfixes and new features

• New: it is now possible to set a reference to the path of a created Content/Location. This allow to use it subsequently when assigning a role with subtree limitation
• Fix: the documentation describing usage of the 'match' keyword for updating/deleting contents and locations was incorrect
• Fix: the documentation describing usage of the 'limitations' keyword for managing roles was incorrect
• Fix: Role creation would not work when using eZPlatform
• BC BREAK: the 'limitation' keyword used to describe role assignments has been replaced by 'limitations' (it was documented using the plural form before)

Complete refactoring of the bundle is here!

After a long series of betas, version 2 is finally here!

Detailed list of changes compared to version 1: https://github.com/kaliop-uk/ezmigrationbundle/blob/master/WHATSNEW.md

Changes compared to version 2.0-beta10:

• allow update of remote_id for locations, thanks to @crevillo
• allow flexible matching of locations to update or delete
• it is now possible to create and delete content languages via migrations
• it is now possible to set references to remote_id when creating contents and locations

One more 'final' release candidate? :-)

Thanks to @lolautruche , the bundle now sports proper support for creating content using specific languages instead of always defaulting to eng-GB.

Other fixes: in beta-9 an unused index on the database table was removed, which proved to be problematic on some versions of Mysql

Final release candidate for version 2

Changes compares to beta7:

• the bundle has now good test coverage (tests execute on Travis with eZPublish versions 2014.3, 2014.11 and eZPlatform 1.4)
• compatibility with older (?) Doctrine versions
• documentation fixes and updates
• fix update of contentType identifier (issue #50)
• fix issue with legacy-kernel Slots and db transactions (issue #53)
• improve stability of content deletion by contentType identifier
• allow setting refs on location creation
• make sure root user does not stay logged in if a migration step fails
• fix command to generate role migrations
• add support for references in object-relation and object-relation-list attributes
• fix reference resolver
• add support for ezcountry fields
• remove leftover var_dump calls

The list of changes since version 1.X is at https://github.com/kaliop-uk/ezmigrationbundle/blob/master/WHATSNEW.md

More tests running on Travis, lots of bugfixes and some new features as well

Changes from beta 6 include:

• better error messages
• references are allowed to select a contentType to update or delete
• contents to be updated/delete can be identified simply by their contentType identifier. This makes it easy to clean the db before removing the contentType itself
• migrations definitions in files available anywhere on disk can now be added to the migrations table
• plenty of bug fixes

For the complete list of changes since version 1.x, have a look at https://github.com/kaliop-uk/ezmigrationbundle/blob/master/WHATSNEW.md

Introduce Travis testing; fix one bug and make compatible with Symfony 2.3

The list of changes since version 1.X is at https://github.com/kaliop-uk/ezmigrationbundle/blob/master/WHATSNEW.md

Complete refactoring of the bundle

See the release notes at https://github.com/kaliop-uk/ezmigrationbundle/blob/master/WHATSNEW.md

Complete refactoring of the bundle

This version is a complete restructuring of the codebase, and brings along with it a few breaking changes.

The main changes are:

• the database table used to store migrations has changed. It uses different columns, and a different name by default, to avoid conflicts with the previous table

• the bundle should now work on PostgreSQL, or any other database supported by Doctrine - it has only been tested on MySQL though :-)

• naming change: what was previously called a version is now called a migration (in the docs, error messages, source code, etc...)

• the generate command takes an optional 2nd argument, it make it easier to create migration definition files with a meaningful name other than "placeholder".
  The options it takes also changed and behave differently from before.

• the status command displays much more information than before:

  • the date that migrations have been executed
  • the reason for migration failure
  • any differences between migrations definitions and the definitions used at the time the migrations were executed

  It also lists all migrations: both the ones available on disk as definition files, and the ones stored in the database (previously if you deleted a migration definition, it would just not be listed any more)

• the update command has been renamed to migrate (but the previous name will be kept as alias for a while)

• the migrate command now prevents concurrent execution of the same migration, stores in the database the reason of failure of execution, warns of invalid migration definitions before execution, makes proper usage of database transactions and probably more

• the location/create action now allows a more flexible way to identify the objects to which the new location is to be added. This will be extended to all other actions in the future

• php migrations are now fully supported (they used to have naming problems)

• the validity of migration definition files is now checked before migration execution is attempted

• the console commands now give more detailed, helpful error messages

• it is much easier now to extend the bundle, as proper Dependency Injection is used everywhere, as well as tagged services