Database triggers en timestamps met default waarde

[Dorgaldir]

Ik heb twee postgresql databases, eigenlijk 1, maar die word geconverteerd naar een 2e en beide moeten tijdelijk naast elkaar draaien tot alle functionaliteit overgebracht is, dus ben ik een sync functionaliteit aan het maken die wijzigingen van de ene naar de andere gaat sturen.

Mijn huidige setup is dat ik bij beide databases een extra tabel heb gemaakt met een sync queue, en een trigger functie die on insert, update en delete getriggerd word. Deze trigger gaat in zijn respectievelijke tabel een record maken met de tabel waarin een record gewijzigd is, de key van dat record en een timestamp die default word ingvuld

Een trigger

code:

CREATE TRIGGER ophaling_recycomqueuetrigger
  AFTER INSERT OR UPDATE OR DELETE
  ON commence.ophaling
  FOR EACH ROW
  EXECUTE PROCEDURE recycom_sync.add_queue();

Hier een voorbeeld van die query

code:

INSERT INTO recycom_sync.sync_queue(sync_queue_id, sync_table, sync_pk) VALUES (gen_random_uuid(), TG_TABLE_NAME, v_pkval);

En op basis van die twee tabellen ga ik de items die gesynct moeten worden, tot daar alles goed.

Maar de functies die getriggerd worden om de data van database 1 naar database 2 te kopiëren is weer een update, waardoor er dan in database 2 weer een trigger afgaat en een nieuwe record aanmaakt waardoor je een loop creëert van data die van de ene naar de andere database gekopieerd word en terug...

Ik ben me hier al een tijdje het hoofd over aan het breken om te bedenken hoe ik dit kan tegenhouden en een onderscheid kan maken tussen een gewone update die door de sync moet, en een update die van een sync komt en dus niet terug moet gaan...

[Verwijderd]

PostgreSQL heeft pg_trigger_depth() die je kunt raadplegen: "current nesting level of PostgreSQL triggers (0 if not called, directly or indirectly, from inside a trigger)"

[Dorgaldir]

Die ga ik zeker eens bekijken, maar de functies om data te kopieren van de ene naar de andere zitten in een externe applicatie die met een timer werkt, dus ik ben niet geheel zeker dat dit het probleem zou oplossen...

[Gomez12]

Laat de externe app dan gewoon logs/hashes van de records opslaan die hij doorgegeven heeft en zolang het niet in de logs/hashes van de vorige run zat is het dus nieuw.

[Harrie_]

Gomez12 schreef op donderdag 7 september 2017 @ 14:45:
Laat de externe app dan gewoon logs/hashes van de records opslaan die hij doorgegeven heeft en zolang het niet in de logs/hashes van de vorige run zat is het dus nieuw.

Dit.
In recycom_sync.add_queue kun je een check doen op je log en op basis daarvan bepalen of de query aan de queue wordt geadd of niet