search

inbo / iassetR

Interact with the iAsset api using R
https://inbo.github.io/iassetR/
Other
0 stars 1 forks source link

`get_record()` doesn't give an ID for each observation. #31

Closed Turtle6665 closed 5 months ago

Turtle6665 commented 6 months ago

Currently, there is no unique ID for each observation.

I feel like the object_id, inspection_id and insp_order are the best options to keep in the final data as they are used in the editCustomInspection which seams to be the API call used to edit observations. More over, the insp_order are the IDs currently used in VespaR.

Those three fields are removed by this step : https://github.com/inbo/iassetR/blob/818e923e16b7ba54f96b7e7334b7475e53bcb148/R/get_records.R#L41C5-L42C46

I'm planning on doing a PR if that's a feature you agree to have.

SanderDevisscher commented 6 months ago

@Turtle6665 the changes you suggest sound usefull, feel free to write the needed changes! If you do a PR add @PietrH & me as reviewers.

PietrH commented 6 months ago

You are right, there is no unique ID per record. There isn't one on iAsset either (at least not in the GUI). We have been asking for one to be added for a while, ideally the same one you can see on the map (currently 6 digit code).

I don't mind you implementing this, but I'm not sure it needs to be exposed to the user by default. Perhaps we can put it behind a flag so this information can be optionally displayed.

How I understand these variables:

While we are at it, it might be a good idea to just fetch all fields outside data. At least internally. Currently we are also dropping:

Why not keep all of them in the internal object, and then expose them as requested? Still, I'd like to know what they mean. Can we use id as a unique identifier? Is it persistent? Can we query by it?

PietrH commented 6 months ago

@Turtle6665 What are you using insp_order for?

Turtle6665 commented 6 months ago

insp_order seems to differ, no clue what it does but I'd like to know!

During my tests, It appeared to me that insp_order was the same number as the ID columns you have when downloading the xlsx from the IAsset GUI.

What are you using insp_order for?

The ID column was used in my code as a unique identifier for each nests' observation. I assumed it would not change over time. Now that I know where it comes from, I don't see any mention of change of persistence of this ID in the API docs.

Keep in mind that you MUST NOT test or use any api calls that can edit the data in iAsset until we have access to a test version. It is not worth the damage we could do. We have requested a test version we can query, and it is supposedly in the works.

I had exactly the same fear, that's why I didn't want to test my theory with the editCustomInspection and the need for the object_id, inspection_id and insp_order.

Can we use id as a unique identifier? Is it persistent? Can we query by it?

From what I saw, this id is always in the form of inspection_id_insp_order. I don't see any way to query data by using it in the docs. Event for the deletion and change, it requires the inspection_id and insp_order in separated fields, so this id doesn't seem to have much use in the API.

PietrH commented 6 months ago

Is there any documentation behind insp_order at all? Can you link me to some if you found any?

Please set me as a reviewer when you get to this.

Turtle6665 commented 6 months ago

No, I didn't find any docs for insp_order. All the information were extrapolated from my testing and from the getCustomInspections doc.

PietrH commented 6 months ago

In that case, be forewarned that insp_order might not be as stable as we'd like. I might not have changed so far, but without a written guarantee I have low confidence in it.

Turtle6665 commented 6 months ago

We have been asking for one to be added for a while, ideally the same one you can see on the map (currently 6 digit code)

insp_order is probably the same one you see on the map. I can't test for all, and it could theoretically be a coincidence, but I've looked at some (see the 3 examples below in public spaces out of the random points I've looked) and the number matches for all.

Note that the code on the map (and therefore the object_id from the API and ID column when downloading from the GUI) can currently have 4 to 7 digits, depending on the record.

Walibi:

Wood in Oostende:

Small wood in Gent:

Even if, it still doesn't say if it's a permanent ID or not, my confidence that it can be used as a unique identifier is now getting higher. More over, if, as I suspect, the insp_order is used to point to nests to edit them in the API, having a changing insp_order feels so counterintuitive as it makes using the API a coding nightmare.

For example, if a request is sent to change an element, and during the way to the server's API (or, less improbable, after the last GET fetch to the API), the insp_order are randomly changed, another nest will be edited and make a big mess.

But anyway, we will have to wait for IAsset to have a definitive answer on this subject.

object_id : Will be the same for all the records, as they are all stored under the same object: VESPAWATCH-001 - Testobject

There is actually one record that has a different object_id (1df578003c154069926b70c4359bf836). It's a weird one, situated in Bulgaria, so it doesn't really matter too much now. Yet, assuming that this object_id would not change in the downloaded data is not true. I would still store the all column as data directly from the API.