I was ignoring the utility of SQL/RDBMS operations. (Am I misremembering or are there libs to do that with flat text "table" data structures already?)
I like that sqlite "how to corrupt" article. It does point out very well that data safety isn't simply application level question/architecture/solution. Leaves me curious about some of the filesystem solutions vs database solutions; again, something I need to read more about. Maybe robustness/safety isn't a high priority for a contest logger, but I contest 99% of the time portable with portable power. A laptop with a good battery does have effectively a built-in UPS, but I like to use other compute solutions like RPis. (Maybe time to add battery UPS-like to my RPi setups?) tangent: Variable length fields are handled easily with line separators delimiting records and space, comma, tab delimiting fields in a record. It may be the UI (especially a TUI) where expected max field length may have value. For example, what's the maximum length callsign I might expect to encounter in a contest or operating event where I'd use tlf? Is there a safe maximum length to use for callsign length? Prefixes and suffixes and some of those special event callsigns make me wonder. Does ITU have anything to say, or is there no upper bound to possible callsign length? tangent: Internationalization... unicode text file for log certainly would work. ASCII would suffice for the contests I participate in including CQ WW. However, if not difficult, internationalization may be a nice to have for folks who would want it, but perhaps not high priority. Just checked the ITU international morse document; that does not have european diacritics or umlauts or anything extra. But there are of course wabun and cryllic and all sorts of internationalization variants to morse. Does anyone contest or do operating events with any of these extended morse character sets? Drew n7da
