You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/Migration.md
+70-5Lines changed: 70 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,9 +1,10 @@
1
-
# Query Migration
1
+
# Migration
2
2
3
3
Entity types and their fields change over time, be it adding fields, moving them between entity types, or completely rethinking the way some fields are handled. As such, we have a robust migration system to ensure that consuming apps will not break, and their queries will continue to work despite any internal FQM changes.
4
4
5
-
-[Query versions](#query-versions)
5
+
-[Versions](#versions)
6
6
-[Updating a query](#updating-a-query)
7
+
-[Updating an entity type](#updating-an-entity-type)
7
8
-[Writing migrations](#writing-migrations)
8
9
-[Changes](#changes)
9
10
-[Entity type changes](#entity-type-changes)
@@ -26,8 +27,10 @@ Entity types and their fields change over time, be it adding fields, moving them
The version of a query is stored inside the FQL string:
33
36
@@ -38,14 +41,28 @@ The version of a query is stored inside the FQL string:
38
41
}
39
42
```
40
43
41
-
These are arbitrary strings, and consuming applications should make no assumptions about them (they are currently integers, but may be changed in the future to commit hashes, module versions, or anything else).
44
+
And versions of custom entity types are stored inside the entity definition:
45
+
46
+
```json
47
+
{
48
+
"id": "d41130e9-0302-5ef3-a6b2-70f6ae1678ce",
49
+
"name": "my_custom_entity",
50
+
"_version": "3"
51
+
}
52
+
```
53
+
54
+
These are arbitrary strings, and consuming applications should make no assumptions about them (they are currently semver-adjacent, but may be changed in the future to commit hashes, module versions, or anything else).
42
55
43
56
Queries from Quesnelia or earlier will have no version associated with them and will be considered version `"0"`.
44
57
45
58
## Updating a query
46
59
47
60
To update a query, send it, the entity type ID, and a list of fields (if desired) to `/fqm/migrate`. See our [API documentation](https://dev.folio.org/reference/api/#mod-fqm-manager) for more information about this endpoint. Our module will return the updated query, entity type ID, and list of fields, all of which should be saved. Additionally, the response may contain [warnings](#warnings), meaning that some parts of the query or field list was unable to be migrated.
48
61
62
+
## Updating an entity type
63
+
64
+
Custom entity types will be migrated when the module is installed. No additional action is required; for more information see [custom entity types support](#custom-entity-types-support).
65
+
49
66
## Writing migrations
50
67
51
68
Any change to an entity type that results in a field being removed or renamed should result in a migration script. The easiest way to do this is to do the following:
@@ -108,7 +125,20 @@ public Map<UUID, UUID> getEntityTypeChanges() {
108
125
109
126
### Defining source maps
110
127
111
-
<!-- TODO: describe this (in next PR) -->
128
+
Source maps are used in migrations to define relations between composite and simple entity types. For example, if your migration alters `simple_instance_status`, it's necessary for the migration system to know that `composite_instances`'s `inst_stat` source points to `simple_instance_status`. To define these relationships, override `getEntityTypeSourceMaps` (note that the inner keys are the source aliases used by the composite):
> Only references from all inheriting composites to the migrated entities need to be defined here — other sources used in parent entities do not need to be explicitly stated.
112
142
113
143
### Warnings
114
144
@@ -346,3 +376,38 @@ public MigratableQueryInformation additionalChanges(Void v, MigratableQueryInfor
- Iterations are done in this order (from the outermost entity to the simplest) and will stop either when a transformation **does** occur (field/condition changes, warning emitted, etc) or when there's no more levels to process.
379
+
380
+
## Custom entity types support
381
+
382
+
> “With great power comes great responsibility”
383
+
>
384
+
> _- Uncle Ben, Spider-Man comics_
385
+
386
+
Custom entity types are incredibly powerful, however, this very power limits the ability for the entities and their queries to be automatically migrated.
387
+
388
+
Currently, FQM will migrate custom entity types based on changes to FQM itself. **No migration is supported for changes made by users to custom entity types.** Here is what FQM will migrate on the entities:
389
+
390
+
- Source entity type ID changes,
391
+
- Source/target join field changes,
392
+
- Default sort order, and
393
+
- Group by definitions.
394
+
395
+
Queries will be migrated just like any other, with the exception of:
396
+
397
+
- If a source's entity type ID changes, queries may not have migrations applicable to that source performed.
398
+
399
+
> [!WARNING]
400
+
>
401
+
> Custom entity migration is done on a “best effort” basis and may not cover all edge cases, nor will it necessarily guarantee a working entity type or query after migration. In the event that something could not be automatically handled (for example, a source's `targetField` is no longer available), a warning will be emitted in the custom entity's `description`. Be sure to check these descriptions and the migration warnings after performing a migration to ensure everything is still as expected.
402
+
>
403
+
> For additional validation, or if you experience issues, follow the [recovery](#recovery) steps below.
404
+
405
+
### Recovery
406
+
407
+
In the event that migration results in a ”broken” entity type (for example, a source no longer exists), it can be easily repaired. To do so, follow these steps:
408
+
409
+
1.`GET` the migrated entity type via `/entity-types/custom/{id}`,
0 commit comments