You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@unomi.apache.org by "Kevan Jahanshahi (Jira)" <ji...@apache.org> on 2023/03/10 19:39:00 UTC

[jira] [Created] (UNOMI-749) Unomi merge system produce inconsistent past sessions rewrite of profileId.

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)