Exporting data¶
To see an example of migrations in action, export data already present in your installation.
To export Repository content, use the ibexa:migrations:generate
command.
This command generates a YAML file with the requested part of the Repository.
The file is located by default in the src/Migrations/Ibexa/migrations
folder
or in a custom folder that you configure.
You can later use this file to import the data.
1 |
|
This generates a file containing all content items. Below you can see part of the output of the default Ibexa DXP installation.
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 |
|
The output contains all the possible information for a future migration command. Parts of it can be removed or modified. You can treat it as a template for another content item for user group. For example, you could:
- Remove
references
if you don't intend to store IDs for future use (see migration references) - Remove
publicationDate
,modificationDate
,locationRemoteId
, as those are generated if not passed (just like in PHP API) - Add
actions
- Add fields for other languages present in the system.
Similarly, you can create update and delete operations.
They are particularly useful combined with match-property
.
This option is automatically added as part of match
expression in the update/delete migration:
1 |
|
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 |
|
Note that you should test your migrations. See Importing data.
Tip
Migration command can be executed with database rollback at the end with the --dry-run
option.
Caution
--siteaccess
option usage can be relevant when multiple languages or multiple repositories are used.
To prevent translation loss, it is recommended that you use the SiteAccess that has all the languages used in your implementation, most likely the Back Office one.
type¶
The mandatory --type
option defines the type of Repository data to export.
The following types are available:
content
content_type
role
content_type_group
user
user_group
language
object_state_group
object_state
section
location
attribute_group
attribute
segment
segment_group
company
If you do not provide the --type
option, the command asks you to select a type of data.
mode¶
The mandatory --mode
option defines the action that importing the file performs.
The following modes are available:
create
- creates new itemsupdate
- updates an existing item. Only covers specified fields and properties. If the item does not exist, causes an error.delete
- deletes an existing item. If the item does not exist, causes an error.
If you do not provide the --mode
option, the command asks you to select the mode.
The following combinations of types are modes 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 |
✔ | ✔ | ✔ |
segment |
✔ | ✔ | ✔ |
segment_group |
✔ | ✔ | ✔ |
company |
✔ |
siteaccess¶
The optional --siteaccess
option enables you to export (or import) data in a SiteAccess configuration's context.
If not provided, the default SiteAccess is used.
It is recommended that you use the SiteAccess of the target repository's Back Office.
Specifying the SiteAccess can be mandatory, for example, when you use several SiteAccesses to handle several languages. Export and import commands only work with languages supported by the context SiteAccess. You must export and import with the SiteAccess supporting all the languages to preserve translations.
This option is also important if you use several repositories with their own databases.
match-property¶
The optional --match-property
option, together with value
, enables you to select which data from the Repository to export.
match-property
defines what property should be used as a criterion for selecting data.
The following properties are available (per type):
content
content_id
content_type_id
content_type_group_id
content_type_identifier
content_remote_id
location_id
location_remote_id
parent_location_id
user_id
user_email
user_login
content_type
content_type_identifier
content_type_group
content_type_group_id
content_type_group_identifier
language
language_code
location
location_remote_id
location_id
object_state
object_state_id
object_state_identifier
object_state_group
object_state_group_id
object_state_group_identifier
role
identifier
id
section
section_id
section_identifier
user
login
email
id
user_group
id
remoteId
attribute
id
identifier
type
attribute_group_id
position
options
attribute_group
identifier
You can extend the list of available matchers by creating a custom one.
value¶
The optional --value
option, together with match-property
, filters the Repository content that the command exports.
value
defines which values of the match-property
should be included in the export.
For example, to export only Article content items, use the content_type_identifier
match property with article
as the value:
1 |
|
Note
The same match-property
and value
is added to generated update
and delete
type migration files.
file¶
The optional --file
option defines the name of the YAML file to export to.
1 |
|
Note
When migrating multiple files at once (for example when calling ibexa:migrations:migrate
without options),
they are executed in alphabetical order.
user-context¶
The optional --user-context
option enables you to run the export command as a specified User.
The command only exports Repository data that the selected User has access to.
By default the admin account is used, unless specifically overridden by this option or in
bundle configuration (ibexa_migrations.default_user_login
).
1 |
|