Hoi @petersaalbrink ik zie dat er helemaal nog niet gereageerd is! Is ook wel een flinke PR die ook ingrijpt in de basis-tabellen. Maar overall lijkt mij de aanpak goed. Met Stetl configs, zonder expliciete XSLT, Python, Jinja, code, respect!
Ik heb ooit voor BAG v1 mutatie-verwerking ontwikkeld, herinner met wat valkuilen, m.n. bijv sortering XML elementen in datum/tijd.

Werkt deze PR voor jou/jullie? Gaat veel tijd kosten voor review en testen. Ik heb zelf die tijd niet momenteel, maar kijk of er een sponsoring of andere samenwerking mogelijk is. Of dat iemand dit leest en hierin wil stappen?

Nog vraag: begrijp ik dat de mutaties uiteindelijk in eigen tabellen komen en te apply-en op een huidige stand, dus de SQL equivalent van de XML mutatie-bestanden zijn?

Hello, will this PR be merged soon?
If I need to process daily mutations, is there another option or is the PR the only way?

@justb4 Ja, deze manier van mutaties verwerken doet al ruim een jaar wat het moet doen voor ons! De mutaties_* tabellen vervullen daarbij een "tussenstation", inderdaad het SQL equivalent van de mutatiebestanden; niet per se noodzakelijk maar was even de makkelijkste oplossing oa. voor de door jou genoemde valkuilen. Ik kan me wel voorstellen dat de use cases voor anderen wellicht net wat verschillen, waardoor een andere aanpak nodig is. Ik heb deze PR dan ook vooral beschikbaar gesteld bij wijze van voorbeeld; kan me inderdaad voorstellen dat er nog wat extra stappen nodig zijn voor dit in NLExtract terecht kan komen.

@WaffiAltaher1 When I worked on this more than a year ago, there was nothing I could find for BAG 2.0 for processing mutations; I don't know about the current situation. Feel free to use this, however! But I won't be able to provide any support.