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

["Kevan Jahanshahi (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/UNOMI-749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kevan Jahanshahi updated UNOMI-749:
-----------------------------------
    Description: 
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.

(There is a commented code in integrations test that suffer from this inconsistency.)

  was:
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.


> 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
>            Priority: Major
>
> 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.
> (There is a commented code in integrations test that suffer from this inconsistency.)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)