Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Use QGIS transaction groups to avoid committing a new parent feature before its children

Aperta
  • Qualcosa non va?
#4,763 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Ambito
databases, mobile

Direzione di ricerca

Start by reading the issue’s references to MMFormPage.qml, MMFormStackController.qml, attributecontroller.cpp, and multieditmanager.cpp, then trace acquireId(), save, and rollback behavior. Check how the app configures QGIS transaction groups and how its providers handle layers across datasources. Done means a defined, verified approach for atomic save and cancel across supported project setups, including the open questions in the issue.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Context

Found while reviewing #4742 (composition relations and delete).

Creating a child feature for a new, unsaved parent currently works like this:

  • MMFormPage.qml calls controller.acquireId(), which adds the parent and commits it (AttributeController::acquireId() ends in commit()), so the child can get a real foreign key.
  • Every form then commits its own layer on save (AttributeController::save() -> commit()).
  • Discarding a new parent therefore has to delete a parent and children that are already on disk (MMFormPage.qml rollbackAndClose()), instead of rolling anything back.
  • Autosync is paused while forms are open (MMFormStackController.qml) so a half-created tree is not synced.

Consequences:

  • Not atomic across layers: a failure between the parent commit and the child commits leaves a committed parent with missing children.
  • If the app is killed mid-form, the early-committed parent stays.
  • Discard needs relation-walking delete logic (#4742) instead of one rollback.
How QGIS does it

QGIS has no acquireId step. Its relation editor copies the parent's referenced field value into the child (QgsAbstractRelationEditorWidget::addFeature). The real id for an unsaved parent comes from transaction groups (project setting "automatic transaction groups"):

  • QgsTransactionGroup opens one provider transaction and starts editing on all layers in the group.
  • Layers in a transaction use QgsVectorLayerEditPassthrough (QgsVectorLayer::createEditBuffer()), so edits go straight into the open transaction and the parent insert returns a real id immediately.
  • The whole group is committed or rolled back together, so cancelling a new parent is a single rollback.
Proposal

Investigate enabling transaction groups for the layers of a project, so that:

  • acquireId() adds the parent inside the open transaction without committing.
  • Save commits the group once, cancel rolls it back, and no relation-walking delete is needed on discard.
Open questions (not verified)
  • Provider support: transactions need a provider that supports them and all layers on the same datasource. What about projects with layers in several files?
  • Passthrough edit mode: there is no edit-buffer undo and failure behaviour differs. rollBack() / commitChanges() are called per layer in many places (attributecontroller.cpp, multieditmanager.cpp) and need auditing.
  • A write transaction held open for the duration of a form session on mobile: how does it interact with sync reading the GeoPackage, and what happens if the app is killed?
  • Who enables it: the app does not set the transaction mode today (no TransactionGroup usage in app, core, test). Is it a project-author setting or something the app forces?
  • How should the app behave on projects that do not use a transaction group?
Related
  • #4742
Lingua principale
C++
Stelle
390
Fork
89
Merge medio
4g 12h
PR unite (30g)
11

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di MerginMaps/mobile

Tutte le issue di MerginMaps/mobile

Issue simili

Altre issue su C++

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.