Skip to content

Set the ids so that they are not dump_only

Here the id field in the device properties, attachments & customfields is no longer dump_only. This allows us to send the id in the payload to patch a device (which we do in the frontend all the time). This id is no longer ignored and will be set to the data (in my testcase a device property). When saving this device property with a given id, sqlalchemy will run the update (and no longer will just save them as new ones, while deleting the orphans afterwards).

I haven't tested it with the configurations, nor with more advanced testcases, but what I did is the following.


import requests

url = "http://0.0.0.0:5000/rdm/svm-api/v1/devices"

payload_create = {
    "data": {
        "type": "device",
        "attributes": {
            "short_name": "abc",
        }
    }
}

requests.post(url, json=payload_create)
requests.get(url).json()
# successful & with id = 1

url = url + "/1"

payload_add_device_property = {
    "data": {
        "type": "device",
        "id": "1",
        "attributes": {
            "short_name": "abc",
            "properties": [{
                "label": "foo"
             }]
        }
    }
}

requests.patch(url, json=payload_add_device_property)
# successful

requests.get(url).json()
# => device property id is 1
payload_update_device_property = {
    "data": {
        "type": "device",
        "id": "1",
        "attributes": {
            "short_name": "abc",
            "properties": [{
                "label": "foobar",
                "id": "1",
            }]
        }
    }
}

requests.patch(url, json=payload_update_device_property)
# successful
requests.get(url).json()
# device property id is still 1

It still somehow would be nice if we would not need to maintain the id here (so there would be some benefits of using a composed primary key out of a device id and the url (for attachments at least), but we need an explicit identifier for the device properties to link them in the locations - so this would be no way to for us here).

Merge request reports

Loading