[
https://issues.apache.org/jira/browse/UNOMI-997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Serge Huber updated UNOMI-997:
------------------------------
Description:
h3. Summary
Unomi 4.0 keeps its built-in definitions (conditions, actions, property types,
built-in rules) in a shared "system" tenant. The data of each site goes in its
own tenant. The migration decides where each 3.0 item goes. On real 3.0 data,
it decides wrongly in three cases:
* Built-in definitions from 3.0 go to the "default" tenant instead of "system".
A tenant's own copy wins over the system one, so Unomi keeps using the old 3.0
versions and hides the improved 4.0 ones. For example, a new visit increases
nbOfVisits but not totalNbOfVisits.
* Place data (geonames) goes to "default", but Unomi reads it from "system".
Location lookups therefore find nothing after the migration.
* The step that fixes the ids of built-in items misses item types written in
camelCase, such as conditionType, actionType and propertyType. It still reports
success.
The goal of this ticket is that, after migration, each item is in the right
tenant and Unomi uses the 4.0 built-in definitions.
See also UNOMI-996, which stops the migration before it gets this far.
h3. Ways to explore
* Assign to "system" only the definitions that Unomi itself ships and reloads
at startup. Everything a user created must go to the tenant, even with the 3.0
scope "systemscope": 3.0 gives this scope to user-created rules, segments and
scorings by default, and items in "system" are shared by every tenant.
* Make this decision from the item type and the list of shipped definitions,
not from the name of the temporary index used during the copy.
* Place data (geonames) is shared reference data and belongs in "system".
* Make the id-fixing step match item types exactly, and log how many items it
changed.
h3. How to test
Manual check: migrate a 3.0.1 data set that contains user-created rules,
segments, scorings and goals, then check the points below.
Automated tests to add. Each must fail on the 4.0.0 release candidate and pass
once the fix is in:
* A test of the tenant decision, one case per kind of item: a shipped condition
type with no scope goes to "system"; a user rule, segment, scoring and goal
with the scope "systemscope" go to "default"; geonames entries go to "system";
profiles, sessions and events go to "default".
* An integration test that checks, after migration, that no user-created item
is in the "system" tenant. This guards against data being shared with every
tenant.
* An integration test that checks, after migration, that the 4.0 built-in
definitions are in use: a new visit increases totalNbOfVisits, and the
definitions of sessionAssigned, pastEventCondition, profilePropertyCondition
and booleanCondition are the 4.0 versions.
* An integration test that a geonames lookup returns results after migration.
* A test of the id-fixing step with camelCase item types: every item is fixed,
and the logged count matches the number of items.
was:
h3. Summary
Unomi 4.0 keeps its built-in definitions (conditions, actions, property types,
built-in rules) in a shared "system" tenant. The data of each site goes in its
own tenant. The migration decides where each 3.0 item goes. On real 3.0 data,
it decides wrongly in three cases:
* Built-in definitions from 3.0 go to the "default" tenant instead of "system".
A tenant's own copy wins over the system one, so Unomi keeps using the old 3.0
versions and hides the improved 4.0 ones. For example, a new visit increases
nbOfVisits but not totalNbOfVisits.
* Place data (geonames) goes to "default", but Unomi reads it from "system".
Location lookups therefore find nothing after the migration.
* The step that fixes the ids of built-in items misses item types written in
camelCase, such as conditionType, actionType and propertyType. It still reports
success.
The goal of this ticket is that, after migration, each item is in the right
tenant and Unomi uses the 4.0 built-in definitions.
See also UNOMI-996, which stops the migration before it gets this far.
h3. Ways to explore
* Assign to "system" only the definitions that Unomi itself ships and reloads
at startup. Everything a user created must go to the tenant, even with the 3.0
scope "systemscope": 3.0 gives this scope to user-created rules, segments and
scorings by default, and items in "system" are shared by every tenant.
* Make this decision from the item type and the list of shipped definitions,
not from the name of the temporary index used during the copy.
* Place data (geonames) is shared reference data and belongs in "system".
* Make the id-fixing step match item types exactly, and log how many items it
changed.
h3. How to test
Migrate a 3.0.1 data set that contains user-created rules, segments, scorings
and goals. Check that:
* none of them is in the "system" tenant,
* no built-in definition is left in "default",
* a new visit increases totalNbOfVisits,
* a geonames lookup returns results.
> After migration from 3.0, some data ends up in the wrong tenant
> ---------------------------------------------------------------
>
> Key: UNOMI-997
> URL: https://issues.apache.org/jira/browse/UNOMI-997
> 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
> Unomi 4.0 keeps its built-in definitions (conditions, actions, property
> types, built-in rules) in a shared "system" tenant. The data of each site
> goes in its own tenant. The migration decides where each 3.0 item goes. On
> real 3.0 data, it decides wrongly in three cases:
> * Built-in definitions from 3.0 go to the "default" tenant instead of
> "system". A tenant's own copy wins over the system one, so Unomi keeps using
> the old 3.0 versions and hides the improved 4.0 ones. For example, a new
> visit increases nbOfVisits but not totalNbOfVisits.
> * Place data (geonames) goes to "default", but Unomi reads it from "system".
> Location lookups therefore find nothing after the migration.
> * The step that fixes the ids of built-in items misses item types written in
> camelCase, such as conditionType, actionType and propertyType. It still
> reports success.
> The goal of this ticket is that, after migration, each item is in the right
> tenant and Unomi uses the 4.0 built-in definitions.
> See also UNOMI-996, which stops the migration before it gets this far.
> h3. Ways to explore
> * Assign to "system" only the definitions that Unomi itself ships and reloads
> at startup. Everything a user created must go to the tenant, even with the
> 3.0 scope "systemscope": 3.0 gives this scope to user-created rules, segments
> and scorings by default, and items in "system" are shared by every tenant.
> * Make this decision from the item type and the list of shipped definitions,
> not from the name of the temporary index used during the copy.
> * Place data (geonames) is shared reference data and belongs in "system".
> * Make the id-fixing step match item types exactly, and log how many items it
> changed.
> h3. How to test
> Manual check: migrate a 3.0.1 data set that contains user-created rules,
> segments, scorings and goals, then check the points below.
> Automated tests to add. Each must fail on the 4.0.0 release candidate and
> pass once the fix is in:
> * A test of the tenant decision, one case per kind of item: a shipped
> condition type with no scope goes to "system"; a user rule, segment, scoring
> and goal with the scope "systemscope" go to "default"; geonames entries go to
> "system"; profiles, sessions and events go to "default".
> * An integration test that checks, after migration, that no user-created item
> is in the "system" tenant. This guards against data being shared with every
> tenant.
> * An integration test that checks, after migration, that the 4.0 built-in
> definitions are in use: a new visit increases totalNbOfVisits, and the
> definitions of sessionAssigned, pastEventCondition, profilePropertyCondition
> and booleanCondition are the 4.0 versions.
> * An integration test that a geonames lookup returns results after migration.
> * A test of the id-fixing step with camelCase item types: every item is
> fixed, and the logged count matches the number of items.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
