[
https://issues.apache.org/jira/browse/UNOMI-445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Serge Huber updated UNOMI-445:
------------------------------
Affects Version/s: 2.0.0
> 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
> Affects Versions: 2.0.0
> 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.
> Despite the impact of these changes, the idea is to keep the REST API as
> compatible as possible for client code. On the GraphQL side, we need to stay
> compliant with the specification, but as the API has never been released, it
> is fine to do some (major) changes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
