Re: ToDo item: switch logfile to database

[Drew Arnett]

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