[
https://issues.apache.org/jira/browse/UNOMI-445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Serge Huber updated UNOMI-445:
------------------------------
Description:
Maybe the best way to do this would be to add a second multivalued field to the
profile. Keep the existing profileID as some kind of "main" or "internal" Unomi
Profile ID, and have a separate field maybe called "profileAliases" that could
be used to lookup a profile using an externally provided profile ID.
For example, if a profile "abc" is called "crmAbc" the Unomi profile would look
something like this:
profiled : "abc"
profileAliases : [ "abc", "crmAbc" ]
It then should be possible to use profileAliases to lookup profiles. In this
story we will also have to check if we could have conflicting profileAliases,
but ideally not.
For lookups. If something like this is done:
GET /context.json
{ "profiled" : "crmAbc" }
This should return the "abc" profile. One way to implement this would be such
an algorithm:
1. If not found, looking using profileAliases
3. If not found, create a profile with that ID if forceCreate is true
Of course we'll have to review and find any other potential consequences that
theses changes might have. Integrations tests will have to be created and
updated to test the new possibilities.
was:
Maybe the best way to do this would be to add a second multivalued field to the
profile. Keep the existing profileID as some kind of "main" or "internal" Unomi
Profile ID, and have a separate field maybe called "profileAliases" that could
be used to lookup a profile using an externally provided profile ID.
For example, if a profile "abc" is called "crmAbc" the Unomi profile would look
something like this:
profiled : "abc"
profileAliases : [ "abc", "crmAbc" ]
It then should be possible to use profileAliases to lookup profiles. In this
story we will also have to check if we could have conflicting profileAliases,
but ideally not.
For lookups. If something like this is done:
GET /context.json
{ "profiled" : "crmAbc" }
This should return the "abc" profile. One way to implement this would be such
an algorithm:
1. If not found, looking using profileAliases
3. If not found, create a profile with that ID if forceCreate is true
> Implement support for multiple profile IDs on Unomi profiles
> ------------------------------------------------------------
>
> Key: UNOMI-445
> URL: https://issues.apache.org/jira/browse/UNOMI-445
> Project: Apache Unomi
> Issue Type: Sub-task
> Reporter: Serge Huber
> Priority: Major
>
> Maybe the best way to do this would be to add a second multivalued field to
> the profile. Keep the existing profileID as some kind of "main" or "internal"
> Unomi Profile ID, and have a separate field maybe called "profileAliases"
> that could be used to lookup a profile using an externally provided profile
> ID.
> For example, if a profile "abc" is called "crmAbc" the Unomi profile would
> look something like this:
> profiled : "abc"
> profileAliases : [ "abc", "crmAbc" ]
> It then should be possible to use profileAliases to lookup profiles. In this
> story we will also have to check if we could have conflicting profileAliases,
> but ideally not.
> For lookups. If something like this is done:
> GET /context.json
> { "profiled" : "crmAbc" }
> This should return the "abc" profile. One way to implement this would be such
> an algorithm:
> 1. If not found, looking using profileAliases
> 3. If not found, create a profile with that ID if forceCreate is true
> Of course we'll have to review and find any other potential consequences that
> theses changes might have. Integrations tests will have to be created and
> updated to test the new possibilities.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
