* loket filter
* cleanup previously migrated data before sync
* increase mu-auth timouts
* split up deletion migration to avoid timouts
* identical utls added catch statements
* deletes before inserts
* Adapt migrations to splitted graphs
* Adapt consumers to the delta-consumer with contexts
* Bump consumers and cache
* Resolve cache not getting cleared
* Flush ministers of non active worship services too
---------
Co-authored-by: Claire Lovisa <lovisa.claire@gmail.com>
This relationship uses the same `org:organization` predicate that is also used for the local involvements relationship. When querying for local involvements data when an organization also has change events data, mu-cl-resources receives the change events data instead and runs into errors. This is likely a bug in the micro service itself. Renaming the predicate is a quick workaround so we have more time to find the real solution for the problem without a broken app.
If only the date is relevant we should not store it as a `datetime` since that would add timezone information which might cause the date to be displayed incorrectly in the frontend.
* Config changes to support the new "change event" data model
* Add mock data that matches the new change event model
This data can be inserted into the database by mounting the folder into the migrations service.
Co-authored-by: Boris De Vloed <boris.de.vloed@gmail.com>
Co-authored-by: Boris De Vloed <boris.de.vloed@gmail.com>
* Setting up file-service
- pre-requisite to download dumps
- pre-requiiste to download the json-diff files
- security considerations: the content of the files created here, is
- assumed to be public data, hence we allow it to be in the public graph
* Bumping deltanotifier and mu-auth, which need
to be able to work with mu-scop-id's
* Delta-producer have multiple background-jobs with different tasks
Hence the introduction of the jobs-controller.
Note: in a more advanced configuration, you can easily extend the
tasks related to one job.
* A pre-requisite to serve dumps, is DCAT api support
The delta-producers make a periodic dump of what is supposed to be
published. They are published according to the DCAT data-model.
Security-considerations: the DCAT producer by the delta-producer flow,
are considered to be public data, hence added to the public graph.
* Introduction of the delta-producer-dump-file-publisher
Service responsible for creating dumps for the (potentially
many) data delta flows.
Here only for the administrative-units, but this can be extended in
the future, in the config.
* Introduction of delta-producer-background-jobs-initiator
This service is responsible for triggering the background jobs related
to the delta-productoin of the administrative-units.
It trigger currently three jobs:
- INITIAL_SYNC: this is the first job to fill the publication graph.
In theory, this is only run once per deploy
- HEALING_JOB: This is a periodic job, which checks what information
is published vs. what information should have been
published (according to a configuration). If differences are found,
because delta-messages never arrived, they are compensated here/
- DUMP_JOB: A periodic job to create a dump of the publication
graph. This is especially useful for consumers, who don't have to
replay the whole delta-diffs, but just can start from the latest sync
point.
* Introduction of delta-producer-publication-graph-maintainer
This service is the core of the logic which determines what should be
published.
The configuration is provided here, and can be elaborated refined in
the config.
It also excutes the healing logic.
* Introduction of delta-producer-json-diff-file-publisher
This simple service, listens to the updates performed on the
publication graph, and serialized these to json-files which are
compatible with current consumers
* Missing dispatcher rules for DCAT
* Various small things:
- outline, whitespaces and comments
* Update README.md
* bump delta-producer-publication-graph-maintainer
* Add organizations (KAL) - Work in progress
* added organizations graph maintainer
* removed inverses, added all bestuur types
* refactored kalliope api
Co-authored-by: Boris De Vloed <boris.de.vloed@gmail.com>
