[
https://issues.apache.org/jira/browse/SYNCOPE-1687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Chicchiriccò updated SYNCOPE-1687:
--------------------------------------------
Description:
The current behavior implemented for propagation task execution is to attempt
to read upfront the object being propagated.
This is mainly done with purpose of:
* translating {{CREATE}} into {{UPDATE}} in case the object is already found
remotely, and viceversa
* avoiding to issue {{DELETE}} operation if object is not found
* avoiding to propagate in case the remote object is found equal to the data
being propagated
There are however conditions under which such checks can be seen as an overhead
rather than an optimization: it makes sense then to let such behavior to be
configurable.
was:
The current behavior implemented for propagation task execution is to attempt
to read upfront the object being propagated.
This is mainly done with purpose of:
* translating {{CREATE}} into {{UPDATE}} in case the object is already found
remotely, and viceversa
* avoiding to issue {{DELETE}} operation if object is not found
* avoid to propagate in case the remote object is found equal to the data being
propagated
There are however conditions under which such checks can be seen as an overhead
rather than an optimization: it makes sense then to let such behavior to be
configurable.
> Allow to configure External Resources not to pre-fetch objects during
> propagation
> ---------------------------------------------------------------------------------
>
> Key: SYNCOPE-1687
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1687
> Project: Syncope
> Issue Type: Improvement
> Components: core
> Reporter: Francesco Chicchiriccò
> Assignee: Francesco Chicchiriccò
> Priority: Major
> Fix For: 3.0.0
>
>
> The current behavior implemented for propagation task execution is to attempt
> to read upfront the object being propagated.
> This is mainly done with purpose of:
> * translating {{CREATE}} into {{UPDATE}} in case the object is already found
> remotely, and viceversa
> * avoiding to issue {{DELETE}} operation if object is not found
> * avoiding to propagate in case the remote object is found equal to the data
> being propagated
> There are however conditions under which such checks can be seen as an
> overhead rather than an optimization: it makes sense then to let such
> behavior to be configurable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
