|
| 1 | +.. _dataset-update-replace: |
| 2 | + |
| 3 | +Dataset Update and Replace |
| 4 | +=============== |
| 5 | + |
| 6 | +Any type of dataset resource can be fully *replaced* with a new version. This operation fully replaces previous content, but maintain metadata and settings for the existing resource. |
| 7 | + |
| 8 | +GeoNode doesn't implement a versioning system, but through the replace and update operations an history of versions can be maintained if these operations are preceded by a **Clone** (*Resource* -> *Save As*) operation. |
| 9 | + |
| 10 | +For vector datasets a more advanced *Update* operation allows updating and inserting new content without a full replacement of pre-existing data. |
| 11 | + |
| 12 | + |
| 13 | +In this section you will learn how to update a *Dataset*. |
| 14 | + |
| 15 | +.. _dataset-replace: |
| 16 | + |
| 17 | +Dataset Replacement (Vector and Raster) |
| 18 | +------------------------ |
| 19 | + |
| 20 | +The :guilabel:`Update dataset` link of the *Edit* menu opens a dialog similar to the one for uploading new datasets. The sidebar, where the new dataset can be selected, shows to buttons at the bottom: :guilabel:`Replace` and :guilabel:`Update`. |
| 21 | + |
| 22 | +.. figure:: img/dataset_update_replace.png |
| 23 | + :align: center |
| 24 | + |
| 25 | + *Updating the Dataset Data* |
| 26 | + |
| 27 | +The **Replace** operation fully removes the existing data and overwrites it with a newly provided dataset. All **resource metadata** (such as title, abstract, keywords, permissions, and links) are preserved, while the underlying data content is entirely replaced. |
| 28 | + |
| 29 | +The process is functionally equivalent to uploading a new dataset, with the key difference that the existing dataset is overwritten rather than creating a new resource. |
| 30 | + |
| 31 | +.. warning:: **Important**: This operation is **not recoverable**. Once completed, it is not possible to restore the previous dataset content. |
| 32 | + |
| 33 | +Behavior and Limitations: |
| 34 | + |
| 35 | +* The dataset identifier and metadata remain unchanged. |
| 36 | +* All existing features or raster data are permanently removed. |
| 37 | +* The operation cannot be undone and should be used with caution. |
| 38 | + |
| 39 | +Dataset Update (Vector) |
| 40 | +------------------------ |
| 41 | + |
| 42 | +For vector datasets, GeoNode provides a more advanced update mechanism known as **Upsert**. This mode allows selectively updating existing features and inserting new ones based on a primary identifier. |
| 43 | + |
| 44 | +The **Upsert** operation compares incoming vector data with the existing dataset and performs one of the following actions for each feature: |
| 45 | + |
| 46 | +* **Update**: If a matching feature already exists, it is replaced with the new one. |
| 47 | +* **Insert**: If no matching feature is found, the new feature is appended to the dataset. |
| 48 | + |
| 49 | +The comparison is performed using a primary key field. |
| 50 | +By default, the field used is **`fid`**, which is treated as the primary identifier of vector features. |
| 51 | +If the incoming dataset contains the `fid` column, DigiNode performs a row-by-row comparison with the existing dataset: |
| 52 | + |
| 53 | + * When a matching `fid` is found, the existing feature is updated. |
| 54 | + * When no match is found, the feature is inserted as a new record. |
| 55 | + |
| 56 | +Because the operation can result in both updates and insertions, it is referred to as an **Upsert**. |
| 57 | + |
| 58 | +Validation and Constraints |
| 59 | +^^^^^^^^^^^^^^^^^ |
| 60 | + |
| 61 | +The Upsert operation integrates with validation constraints defined at the GeoServer level. |
| 62 | + |
| 63 | +From **GeoServer version 2.27.3**, it is possible to `define validation constraints on vector feature types <https://docs.geoserver.org/main/en/user/data/webadmin/layers.html#feature-type-details-vector>`_, including: |
| 64 | + |
| 65 | +* Allowed value ranges for numeric fields |
| 66 | +* Enumerated lists of accepted values for numeric or textual fields |
| 67 | + |
| 68 | +If such constraints are defined on the feature type: |
| 69 | + |
| 70 | +* DigiNode automatically applies them during the Upsert operation. |
| 71 | +* Each incoming feature is validated against these constraints. |
| 72 | +* If any feature violates the defined rules, the Upsert process is **stopped** and an error is returned. |
| 73 | + |
| 74 | +Error Handling and Logging |
| 75 | +^^^^^^^^^^^^^^^^^ |
| 76 | + |
| 77 | +When validation errors or processing issues occur: |
| 78 | + |
| 79 | +* The Upsert operation is aborted. |
| 80 | +* A **detailed error message** is returned to the user. |
| 81 | +* A **log file** is generated at the end of the operation. |
| 82 | + |
| 83 | +This log file is available in the **Assets panel** of the dataset and contains: |
| 84 | + |
| 85 | +* A row-by-row report of processed features |
| 86 | +* Details of successful updates or insertions |
| 87 | +* Descriptions of validation failures or rejected records |
| 88 | + |
| 89 | +.. warning:: The same conditions apply as for the replace operation |
| 90 | + |
| 91 | + - The Upsert operation is **not recoverable**. |
| 92 | + - Existing features may be permanently overwritten. |
| 93 | + - Careful validation of the input data is strongly recommended before execution |
0 commit comments