[
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:
profileId : "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.
Add clientId to ContextRequest object as an optional parameter (if null we use
a default client ID). Modify profile creation logic in ContextJsonEndpoint to
add the alias to a newly created profile.
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:
profileId : "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.
> 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
> Assignee: Anatol Sialitski
> Priority: Major
> Fix For: 2.0.0
>
>
> 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:
> profileId : "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.
> Add clientId to ContextRequest object as an optional parameter (if null we
> use a default client ID). Modify profile creation logic in
> ContextJsonEndpoint to add the alias to a newly created profile.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
