Kevan Jahanshahi created UNOMI-749:
--------------------------------------
Summary: Unomi merge system produce inconsistent past sessions
rewrite of profileId.
Key: UNOMI-749
URL: https://issues.apache.org/jira/browse/UNOMI-749
Project: Apache Unomi
Issue Type: Improvement
Affects Versions: unomi-2.1.0
Reporter: Kevan Jahanshahi
In case a profile is merge. There is a mechanism that will update all previous
sessions to use the new master profileID:
{code:java}
List<Session> oldSessions = persistenceService.query("profileId",
profileToBeMergeId, null, Session.class);
for (Session oldSession : oldSessions) {
if (!oldSession.getItemId().equals(event.getSession().getItemId())) {
persistenceService.update(oldSession, Session.class, "profileId",
anonymousBrowsing ? null : mergedProfileId);
}
} {code}
The sessions profileID is correctly updated in ElasticSearch documents.
But when you load the session using persistenceService, you still get the old
profileId. This is due to the deserialisation of the session, we correctly
updated the profileId prop, but the profile property is still containing the
full old profile.
The session properties:
* profileId: new profile ID
* profile: old profile
And the Session object contains this setter:
{code:java}
/**
* Sets the associated Profile.
*
* @param profile the associated Profile
*/
public void setProfile(Profile profile) {
this.profileId = profile.getItemId();
this.profile = profile;
} {code}
So if the session still contains the old profile, once deserialised, the
profileID will always be the old one.
So we have an inconsistency here.
Example:
in ElasticSearch after a merge we can have this:
{code:java}
{
"profileId": "profileA"
"profile": {
"itemId": "profileB"
}
}{code}
And once loaded in the code the session.profileId will be: profileB.
The merge code should be fixed to avoid such inconsistency and may be we need
to update that setter that seem's a bit error prone.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
