Architecture

The components

The extension owns a schema called agol_fdw that holds three things: a metadata catalog (what it learned about each AGOL layer), queue and log tables (the outbox, inbound_queue, conflict_log, validation_issues, sync_run_log), and plpython3u functions callable from SQL.

The materialized feature tables themselves live in an ordinary schema you choose (default data) — they're plain Postgres + PostGIS tables, not locked inside the extension. A standalone Python worker drains both queues (woken via LISTEN/NOTIFY).

The data flow

Outbound — PostGIS → AGOL

1. You write to a materialized table (e.g. data.poles).
2. An AFTER trigger writes to the outbox in the same transaction — rollback cancels both.
3. The worker reads the outbox with FOR UPDATE SKIP LOCKED and pushes to AGOL via the GeoServices REST API (applyEdits / append / addFeatures / updateFeatures / deleteFeatures).

Inbound — AGOL → PostGIS

1. An edit happens in ArcGIS Online.
2. AGOL fires a Feature Service webhook to inbound_queue.
3. The worker applies the edit with optimistic concurrency keyed on agol_version — conflicts go to conflict_log, never auto-resolved.

System columns

Materialized tables carry a few extra columns the bridge relies on:

• objectid bigint — the AGOL object id.
• globalid uuid — the AGOL global id.
• agol_version bigint — the version used for optimistic concurrency.

← Back to home