Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#4,763 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Lĩnh vực
databases, mobile

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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
Ngôn ngữ chính
C++
Star
390
Fork
89
Merge trung bình
4 ngày 23 giờ
Pull request đã merge (30 ngày)
13

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của MerginMaps/mobile

Tất cả issue của MerginMaps/mobile

Issue tương tự

Thêm issue về C++

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.