Flash Data Storage (FDS): What is the point of "Files" and "Records"

[awneil]

I find the documentation completely opaque as to the meaning and intended application of what FDS calls  "Files" and "Records".

It seems that what FDS calls a "File" bears no relation at all to the concept of a file as a "container" - as found in other usages.

"Files" and "Records" just seem to be completely unrelated, unconnected, arbitrary identifiers - is that right?

In the SDK 15 FDS example, a complete config structure is stored as a single "Record".

What would be the pros & cons of storing the individual config elements as separate "Records" ?

Would it make any difference if they all had the same "File" ID or not ?

[Jørgen Holmefjord]

Hi,

I think this is well explained in the documentation:

The Flash Data Storage API exposes functions to manipulate files and records. Files consist of one or more records, which contain the actual data.

Every record is identified by a key and assigned to a file through the file ID. Files are basically groups of records. Neither record keys nor file IDs must be unique, and files can contain several records with the same key. Records can be accessed through any combination of file ID and record key.

For example, an application could use the following two files:

• File 1 with two records: 0x1111="Phone1", 0x2222="data: 12345"
• File 2 with three records: 0x1111="Tablet1", 0x2222="data: abcdef", 0x2222="data: 67890"

You could then iterate, for example, through all records in file 1, through all records with key 0x1111, or through all records with key 0x2222 in file 2.

Best regards,
Jørgen

[awneil]

I still don't see how the "files" actually contain anything - especially given this:

The Record ID and File ID don't seem to have any hierarchical relationship.

But the real question is:

awneil said:

In the SDK 15 FDS example, a complete config structure is stored as a single "Record".

What would be the pros & cons of storing the individual config elements as separate "Records" ?

Would it make any difference if they all had the same "File" ID or not ?

[Andy]

I think it's more like a useful feature to separate or organize your records. While it is not a hierarchy per se, you can still identify different "groups" of records. I, for instance, use them in my application to distinguish records between settings and errors. By separating them in files I can, for example, check if any errors have occurred just by checking the number of records in the errors file. How you use them is application dependent. You don't need to use them if all your records belong to the same "category".

[awneil]

I think it's the term "file" that I find misleading.

AFAIKS, all records are  entirely separate and independent - there is no structure or hierarchy or grouping.

Each record has 2 identifiers which you can use arbitrarily in any way you want; eg, you could keep either one of them fixed to show that all records sharing that ID are "related".

Like the "Tags" for posts in this forum ...

[tesc]

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.

[emdi]

Yep, "files" as such don't exist in flash. You can see files as a collection of records but that doesn't mean that a record is contained in a file in the flash. The API simply lets you operate on files as a collection of records.