Actual Content Constraints generated during point in time release not valid for DE filtering
Transferring data using Gingerbread version
- from live design space dataflow
- to pit disseminate space dataflow
now creates only one single actual content constraint with
- validFrom = initial transfer request time
- validTo = scheduled release time
This indicates no valid actual content constraint after the release time.
This impacts the filtering in DE, with the created content constraint only applying to filters between the schedule and release time:
After the release time the filters no longer adapt to the information provided by the invalidated content constraint:
Previously our point in time releases would have two actual content constraints (see: #69 (closed)):
- one validTo release time for data being replaced
- another validFrom release time for the new data being transferred
E.g., if the PIT release datetime is set to 30/01/2020 12:00:00:
ACC version | validFrom | validTo | validity time span |
---|---|---|---|
Live | unlimited | 30/01/2020 11:59:59 | all past times --> 30/01/2020 11:59:59 --------------------- |
Pit | 30/01/2020 12:00:00 | unlimited | ------------------- 30/01/2020 12:00:00 --> all future times |
This regression could be reproduced in QA when transferring data for any dataflow from reset to stable (with and without the restoration option).
Edited by Jens Dossé