[
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. when working on this, please uncomment the code, search for the
ticket number in the sources.)*
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.
(There is a commented code in integrations test that suffer from this
inconsistency.)
> 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. when working on this, please uncomment the code, search for
> the ticket number in the sources.)*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
