FDS record update increments record ID, and calls event handler twice

RE: FDS record update increments record ID, and calls event handler twice

Simonr — Thu, 28 Nov 2019 09:48:10 GMT

Hi Paul

Yes, I guess record count would be a more descriptive name of it. The Record ID is indeed an internal ID used to "keep track of" every record and a way to see where the previous records are written are in relation to one another. It is exposed so that people may use this to keep track of their records as well, but for your specific use case, it seems like file_id and record_key would be better suited.

Best regards,

Simon

RE: FDS record update increments record ID, and calls event handler twice

BEplane — Wed, 27 Nov 2019 14:07:10 GMT

So the Record ID isn't really an ID, but more of a Record Count, or Record Update Count?

And in this case the data wouldnt be considered duplicate, as it is being discarded, or marked as dirty. And the record persists in a different physical memory location, but the record/data is still intended to be the same. The Record ID seems to an internal FDS feature being exposed? It is my understanding that the FDS API is suppose to provide high level functionality for the fstorage. So the valid or expected use of the record ID is unclear?

RE: FDS record update increments record ID, and calls event handler twice

Simonr — Wed, 27 Nov 2019 09:58:19 GMT

Hi Paul

Sorry about causing any confusion, I thought those threads would be helpful, but obviously, they weren't in your case.

So, the reason you're seeing two (and three) record IDs is that the fds_record_update first writes a new record to flash, then deletes the old record. Described in the documentation under fds_record_update This is due to the physical properties of the flash memory, as you are only able to erase full pages, so when you want to update a record you'll have to write a new one and mark the old one as dirty.

This means that it won't be possible to have just one set of data in the FDS I'm afraid, as the data will technically be duplicated, as it is marked as dirty during an update and will stay until you call a garbage collection. Even though the record and file ID aren't guaranteed to be unique, won't this be sufficient to identify your data correctly? You can alternatively, set your own ID as part of the data for identification.

Best regards,

Simon

RE: FDS record update increments record ID, and calls event handler twice

BEplane — Tue, 26 Nov 2019 14:34:07 GMT

I did not link any threads in my post, but I have seen both of these threads before and liked them. Also neither of the threads have a definitive explanation to clear up how the Record ID, Record Key, and File Key can be used. Linking to other threads that are not properly answered only creates a web of confusion. This helps no one.

I do not see where the thread speaks about the record ID increasing. Can you explain this in more depth?

[quote userid="8164" url="~/f/nordic-q-a/35843/flash-data-storage-fds-what-is-the-point-of-files-and-records/138084"]That is correct. You have two sets of identifiers, one named file and the other named record, that you can use however you want to "tag" the entries.[/quote]

File Key, and Record Key, are the identifiers I can use 'however' I would like.

I would like a single structure stored in persistent flash. I would like to update the values of this structure and get the values of the structure. I do not want to create multiple Record IDs, or in other words duplicate data, I only want 1 set of data. Is this possible with the FDS?

Additionally, why is the Record ID Increasing? and does this in fact mean there is a duplicate record?

RE: FDS record update increments record ID, and calls event handler twice

Simonr — Tue, 26 Nov 2019 13:02:10 GMT

The record ID (and record key for that matter), are discussed and explained thoroughly in this thread and the thread linked to. I hope this will help you understand why the record ID is increasing.

As for why FDS_EVT_UPDATE occurs twice, that has to be because the update is called twice somewhere in your application whether you're aware of it or not.

Best regards,

Simon