Discovery record naming: include the parent folder in the record name?

[lcalisto]

Discovery currently names each record after the file name alone. Problems found in the 2025 archive layout:

Raw UHRS files are literally named rev1.segy inside per-line folders (e.g. LEI_25_M143_SOL/rev1.segy, FIG_25_M096_SOL/rev1.segy), so many records would get identical names.

The record name is unique per survey mission, so the second rev1.segy in a mission would fail to be created and records silently lost during discovery. Or I'm I missing something?

Proposal: name records {parent folder}/{file name}, truncated to the name limit?

@ricardogsilva What do you think? have we discuss this with Vasco? If so I don't remember.

Relates to #116.

[ricardogsilva]

I guess the fix for this is to lift the restriction of names being unique for a mission.

The only realistic way to set a record's name from discovery is to use the filename of its underlying asset. And if files have similar names within the same mission, then we need to allow the respective records to be created with similar names too.

What we can perhaps do is put a unique clause on the path of the asset in order to ensure we don't register the same asset twice.

In addition to this, the UI needs to clearly differentiate records, perhaps by always showing both the name and the id.

[ricardogsilva]

In addition to my previous comment, the UI needs to allow filtering records by their corresponding assets' path.

This will allow finding relevant records by typing a fragment of their path.

[lcalisto]

Fully agree, lifting the unique-name restriction is a possible fix, and filename-as-name keeps things predictable. Just two notes:

The unique clause on the asset path has to be per mission. Two missions can legitimately have the same relative path. recordasset has no mission FK, so this needs either the mission id on the asset or an application-level check.

Showing the asset's path in the record listings would also help when many records share a filename like rev1.segy. Don't you think?

Who takes this one, you or me? I'm fine either way. 😄 Just note that the extractors work in #116 depends on it. In any case I'm testing with 2024 data, so I'm not blocked.