[Feature]: Save GeoPackage edits back to their source table (PostGIS parity) #1041

Before you start

• I searched existing issues and the roadmap for duplicate requests.

What problem does this solve?

The Data at the source roadmap item asks for edits to be written back to GeoPackage and PostGIS instead of staying only in the project.

The PostGIS part has now landed in #671. It provides an explicit load-for-editing workflow, pending insert/update/delete counts, pg.saveEdits and pg.discardEdits. Saves use a transaction and row-version checks to refuse conflicting changes. The current UI exposes these through Home › Add Data › Database… › Load for editing and Edit › Manage Edits; the original PR described a separate tab, but that is not the current placement.

The remaining gap is GeoPackage source-table write-back. Its desktop provider opens files read-only. The existing GeoPackage writer exports a new file and deliberately refuses an existing destination. Editing a loaded GeoPackage layer therefore does not provide a way to save those edits back to its original table.

This matters for users maintaining an existing GeoPackage containing several layers: exporting another file is not the same as updating the original dataset used by other projects and tools.

Proposed solution

Add an explicit desktop workflow for editing an existing local GeoPackage feature table and saving or discarding its pending edits. Follow the command-based save/discard pattern already established for PostGIS, without requiring a new ribbon tab or a provider abstraction as part of this issue.

• Retain the source file, table, geometry column and stable feature keys, plus a baseline captured before editing.
• Show pending inserts, updates and deletions, and make the distinction between saving the project, saving to the source, and exporting clear.
• Apply row-level changes to the existing table in one transaction. Do not replace the file or rebuild the table from the loaded features.
• Discard reloads the source table; a successful save refreshes the edit baseline and any affected view/cache.
• Coordinate the design before implementation, as required by this roadmap item.

Acceptance criteria

• Attribute and geometry changes, inserted features and deleted features persist when the original GeoPackage is reopened independently.
• Other tables, unedited rows and untouched column values remain intact. A filtered or partially loaded layer must never cause rows outside its loaded editing scope to be deleted.
• Preserve valid source feature IDs and reconcile generated IDs for inserted features. Write geometry in the source coordinate system and keep its supported type/dimensions; refuse unsupported cases rather than silently losing data.
• Maintain the affected table’s spatial index and relevant GeoPackage metadata while respecting its constraints and triggers.
• Detect conflicting external changes to rows being saved and refuse the save rather than silently overwriting them. File locks, read-only files, constraint failures and other write errors leave no partial save, retain pending edits, and report the failure clearly.
• Define save/discard and undo/redo behavior consistently with the PostGIS workflow: undoing local state must not imply the external database transaction was undone or allow a stale baseline to be saved again unsafely.
• Source writes remain explicit and use the appropriate existing approval/permission checks for AI and plugin callers.
• Cover successful mixed insert/update/delete saves, unchanged data preservation, external-change conflicts, transaction rollback, and repeated save/discard behavior with behavioral regression tests and an end-to-end smoke run.
• Keep the web build working. Initial scope is a writable local desktop file, not writing back into browser uploads, remote downloads or temporary copies.

Scope boundaries and related work

• feat(postgis): a PostGIS tab to connect, edit and save tables, refusing conflicts #671 already delivers PostGIS row editing; do not reimplement it here. PostGIS table creation and schema/table/column management are separate work.
• [Bug]: Exporting into an existing GeoPackage deletes its other tables #852 fixed destructive GeoPackage export by refusing existing destinations. This issue must preserve that protection. Adding or replacing a whole table during export is a separate roadmap item, not source-row editing.
• Schema editing and editable standalone tables are outside this issue.
• Update the roadmap and user documentation when this lands, distinguishing completed PostGIS support from the remaining GeoPackage work.

Code inspected: crates/engine/src/cmd/pg.rs, crates/data/src/source/postgis.rs, and crates/data/src/source/gpkg.rs. Current usage is documented under Editing PostGIS tables and Writing. This issue is based on code/docs inspection; no new live PostGIS write verification is claimed.

Estimated scope

Not sure — provider changes and source-write safety need coordination.

Alternatives considered

Keep edits in the project or export a new GeoPackage. Both remain useful, but neither updates the original source table.