[
https://issues.apache.org/jira/browse/UNOMI-996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Serge Huber updated UNOMI-996:
------------------------------
Description:
h3. Summary
When you follow the 3.0 to 4.0 migration guide on real 3.0 data, the migration
stops almost at once with the message "no mapping found in bundles".
The guide asks you to run the migration before Unomi is started. At that point,
Unomi has not yet loaded the parts that contain the index definitions the
migration needs. In 3.0 these parts were loaded at boot, so the same steps
worked.
A second problem stops the migration later. Some indices have no known
definition, and the migration stops on them instead of handling them. Every 3.0
cluster has one of these, the cluster node index. Clusters that saved a
Salesforce connector configuration have another.
The goal of this ticket is that the documented steps migrate a real 3.0 data
set to the end.
h3. Ways to explore
* Make the index definitions available to the migration command itself, rather
than starting all Unomi services first. Unomi should not answer requests before
the migration has finished.
* Give the cluster node index a known definition. For other unknown indices,
copy their current definition and assign their documents to the "default"
tenant, like other site data. Never assign them to "system", and never leave
documents without a tenant.
* If a manual step is still needed, add it to the migration guide.
h3. How to test
Manual check: start from a Unomi 3.0.1 data set that includes the cluster node
index and a Salesforce connector configuration. Follow the migration guide step
by step. The migration must finish with no error.
Automated tests to add. Each must fail on the 4.0.0 release candidate and pass
once the fix is in:
* An integration test that runs the migration with only the features installed
at boot, exactly as the guide describes, and checks that it finishes. This is
the main regression guard: today the test setup installs everything first,
which hides the problem (see UNOMI-998).
* An integration test with a cluster node index and an index of an unknown type
in the source data. The migration must finish, keep all their documents, and
give every document the "default" tenant. No document may be left without a
tenant, and none may go to "system".
* A unit test for the mapping lookup: a known type with no bundled file
(cluster node) is found, and an unknown index falls back to its current
definition instead of failing.
was:
h3. Summary
When you follow the 3.0 to 4.0 migration guide on real 3.0 data, the migration
stops almost at once with the message "no mapping found in bundles".
The guide asks you to run the migration before Unomi is started. At that point,
Unomi has not yet loaded the parts that contain the index definitions the
migration needs. In 3.0 these parts were loaded at boot, so the same steps
worked.
A second problem stops the migration later. Some indices have no known
definition, and the migration stops on them instead of handling them. Every 3.0
cluster has one of these, the cluster node index. Clusters that saved a
Salesforce connector configuration have another.
The goal of this ticket is that the documented steps migrate a real 3.0 data
set to the end.
h3. Ways to explore
* Make the index definitions available to the migration command itself, rather
than starting all Unomi services first. Unomi should not answer requests before
the migration has finished.
* Give the cluster node index a known definition. For other unknown indices,
copy their current definition and assign their documents to the "default"
tenant, like other site data. Never assign them to "system", and never leave
documents without a tenant.
* If a manual step is still needed, add it to the migration guide.
h3. How to test
Start from a Unomi 3.0.1 data set that includes the cluster node index and a
Salesforce connector configuration. Follow the migration guide step by step.
The migration must finish with no error.
> Migration from Unomi 3.0 stops before it finishes
> -------------------------------------------------
>
> Key: UNOMI-996
> URL: https://issues.apache.org/jira/browse/UNOMI-996
> Project: Apache Unomi
> Issue Type: Bug
> Affects Versions: unomi-4.0.0
> Reporter: Serge Huber
> Priority: Blocker
> Fix For: unomi-4.0.0
>
>
> h3. Summary
> When you follow the 3.0 to 4.0 migration guide on real 3.0 data, the
> migration stops almost at once with the message "no mapping found in bundles".
> The guide asks you to run the migration before Unomi is started. At that
> point, Unomi has not yet loaded the parts that contain the index definitions
> the migration needs. In 3.0 these parts were loaded at boot, so the same
> steps worked.
> A second problem stops the migration later. Some indices have no known
> definition, and the migration stops on them instead of handling them. Every
> 3.0 cluster has one of these, the cluster node index. Clusters that saved a
> Salesforce connector configuration have another.
> The goal of this ticket is that the documented steps migrate a real 3.0 data
> set to the end.
> h3. Ways to explore
> * Make the index definitions available to the migration command itself,
> rather than starting all Unomi services first. Unomi should not answer
> requests before the migration has finished.
> * Give the cluster node index a known definition. For other unknown indices,
> copy their current definition and assign their documents to the "default"
> tenant, like other site data. Never assign them to "system", and never leave
> documents without a tenant.
> * If a manual step is still needed, add it to the migration guide.
> h3. How to test
> Manual check: start from a Unomi 3.0.1 data set that includes the cluster
> node index and a Salesforce connector configuration. Follow the migration
> guide step by step. The migration must finish with no error.
> Automated tests to add. Each must fail on the 4.0.0 release candidate and
> pass once the fix is in:
> * An integration test that runs the migration with only the features
> installed at boot, exactly as the guide describes, and checks that it
> finishes. This is the main regression guard: today the test setup installs
> everything first, which hides the problem (see UNOMI-998).
> * An integration test with a cluster node index and an index of an unknown
> type in the source data. The migration must finish, keep all their documents,
> and give every document the "default" tenant. No document may be left without
> a tenant, and none may go to "system".
> * A unit test for the mapping lookup: a known type with no bundled file
> (cluster node) is found, and an unknown index falls back to its current
> definition instead of failing.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
