Importing data¶
To import data from YAML migration files into Repository, you run the ibexa:migrations:migrate
command.
The ibexa:migrations:import
command automatically places migration files in the correct folder.
Alternatively, you can place the files manually in the src/Migrations/Ibexa/migrations
folder
or in a custom folder that you configure,
and specify the file name within this folder as parameter.
If you do not specify the file, all files within this directory are used.
1 |
|
Migrations store execution metadata in the ibexa_migrations
database table.
This allows incremental upgrades:
the ibexa:migration:migrate
command ignores files that it had previously executed.
Available migrations¶
The following data migration steps are available:
create |
update |
delete |
|
---|---|---|---|
content |
✔ | ✔ | ✔ |
content_type |
✔ | ✔ | |
role |
✔ | ✔ | ✔ |
content_type_group |
✔ | ✔ | |
user |
✔ | ✔ | |
user_group |
✔ | ✔ | |
language |
✔ | ||
object_state_group |
✔ | ||
object_state |
✔ | ||
section |
✔ | ✔ | |
location |
✔ | ||
attribute_group |
✔ | ✔ | ✔ |
attribute |
✔ | ✔ | ✔ |
customer_group |
✔ | ✔ | ✔ |
currency |
✔ | ✔ | ✔ |
product_price |
✔ | ||
segment_group |
✔ | ✔ | ✔ |
segment |
✔ | ✔ | ✔ |
setting |
✔ | ✔ | ✔ |
Repeatable steps¶
You can run a set of one or more similar migration steps multiple times by using the special repeatable
migration type.
A repeatable migration performs the defined migration steps as many times as the iterations
setting declares.
1 2 3 4 5 |
|
Tip
You can use repeatable migration steps, for example, to quickly generate large numbers of Content items for testing purposes.
You can vary the operations using the iteration counter.
For example, to create five Folders, with names ranging from "Folder 0" to "Folder 4", you can run the following migration using the iteration counter i
:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|
To vary the content name, the migration above uses Symfony expression syntax.
In the example above, the expression is enclosed in ###
and the repeated string SSS
.
Note
Iteration counter is assigned to i
by default, but you can modify it in the iteration_counter_name
setting.
Generating fake data¶
You can also generate fake data with the help of FakerPHP
.
To use it, first install Faker on your system:
1 |
|
Then, you can use faker()
in expressions, for example:
1 2 3 |
|
This step generates Field values with fake personal names.
Expression syntax¶
You can use Symfony expression syntax in data migrations. It is especially useful in repeatable steps, where you can use it to generate varied content in migration steps.
The expression syntax uses the following structure: ###<IDENTIFIER> <EXPRESSION> <IDENTIFIER>###
The IDENTIFIER
can be any repeated string that encloses the actual expression.
Migration examples¶
The following examples show what data you can import using data migrations.
Content Types¶
The following example shows how to create a Content Type with two Field definitions.
The required metadata keys are: identifier
, mainTranslation
, contentTypeGroups
and translations
.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
|
Content items¶
The following example shows how to create two Content items: a folder and an article inside it.
When creating a Content item, two metadata keys are required: contentType
and mainTranslation
,
as well as parentLocationId
.
To use the Location ID of the folder, which is created automatically by the system,
you can use a reference.
In this case you assign the parent_folder_location_id
reference name to the Location ID,
and then use it when creating the article.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 |
|
Roles¶
The following example shows how to create a Role.
A Role requires the identifier
metadata key.
For each Policy assigned to the Role, you select the module and function, with optional Limitations.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
|
Users¶
The following example shows how to create a user.
The required metadata keys are: login
, email
, password
, enabled
, mainLanguage
, and contentType
.
You also need to provide the user group's remote content ID.
You can use an action to assign a Role to the user.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
|
Language¶
The following example shows how to create a language.
The required metadata keys are: languageCode
, name
, and enabled
.
1 2 3 4 5 6 7 |
|
Product catalog¶
The following example shows how to create an attribute group with two attributes:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
|
You can also update attributes, including changing which attribute group they belong to:
1 2 3 4 5 6 7 8 9 10 11 12 |
|
You cannot change the attribute type of an existing attribute.
Product type¶
The following example shows how to create a product type.
The main part of the migration file is the same as when creating a regular Content Type.
A product type must also contain the definition for an ibexa_product_specification
Field.
fieldSettings
contains information about the product attributes.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
|
Customer groups¶
The following example shows how to create a customer group with a defined global price discount:
1 2 3 4 5 6 |
|
Currencies¶
The following example shows how to create a currency:
1 2 3 4 5 |
|
Prices¶
The following example shows how to create a price for a product identified by its code:
1 2 3 4 5 |
|
Segments ¶
The following example shows how to create a segment group and add segments in it:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
When updating a segment group or segment, you can match the object to update by using its numerical ID or identifier:
1 2 3 4 5 6 |
|
Settings¶
The following example shows how you can create and update a setting that is stored in the database:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
Taxonomies¶
The following example shows how you can create a "Car" tag in the main Taxonomy:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
|
The field identifiers must match the identifiers used in the ibexa_taxonomy
configuration file.
If the Content Type associated with the tags is changed, the configuration should be adjusted when creating migrations.
Note
If there are multiple taxonomies, the taxonomy
field is then necessary here (line 21).
You can use the following example to assign tags to a Content (Content Type Article has an additional Field):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 |
|
When updating a Content Type, use:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
|
Criteria¶
When using update
or delete
modes, you can use criteria to identify the objects to operate on.
Caution
Criteria only work with objects related to the product catalog.
1 2 3 4 5 6 7 8 9 10 |
|
Available operators are:
=
<>
<
<=
>
>=
IN
NIN
CONTAINS
STARTS_WITH
ENDS_WITH
You can combine criteria by using logical criteria and
and or
:
1 2 3 4 5 6 7 8 9 |
|
Criteria can be nested.