* On 2023 28 Dec 08:57 -0600, Alan Dove wrote: > Hey, folks: > > I'm opposed to having TLF rely on a database. It adds complexity and > failure points, and shouldn't be necessary for any forseeable contest > log.
I think this is a good point particularly in the logging space where Tlf is mostly used as a logger for single operator efforts. > Users who want a tool to collect QSOs from multiple contests for > analysis, DXCC tracking, and so forth should use a separate > application. CQRLog does all that and more, and also exemplifies the > kinds of support problems a database can add - just browse through the > CQRLog forums for tales of woe from users who can't get the database > connection working properly. CQRlog was also my first thought and I do use it though I do not aggregate my contest event log data into it. However, CQRlog is X11 GUI only and is not a solution for anyone working only in the console (that's not an argument toward having Tlf depend on a DB). There are also online log repositories but one has to constantly upload to them and rely on the services offered to make use of the data. The somewhat misnamed Logbook of The World does not import a considerable amount of uploaded ADIF data as it is only intended to retain data needed for ARRL and CQ WAZ award tracking. The list of compromises with these services goes on. CQRlog depends on Mysql/Mariadb and can use it in two modes. The first is the usual where the server process is running on localhost or a remote host and the second where it acts a bit like SQLite by starting a private server that saves the DB in the user's home directory hierarchy. I use the second method as it avoids having to become a DB administrator. For those unfamiliar, SQLite is an embedded DB. It saves the database to a single file that can be specified at run time. Like the current log file the SQLite database file would be written in the working directory for a given event. While SQLite supports transactions internally, the single file is still subject to anything that affects the file system in use. Backups are relatively easy by simply copying the file though care should be take to ensure a write is not in progress. How much that differs from copying the present log file merits investigation. An advantage to SQLite would be the ability to quite easily construct queries in the SQL syntax that would require custom C code with a flat text file. That said, text has the advantage that many tools can work with it from the shell prompt or with higher level scripting languages (editing log data at runtime would likely require custom code whereas now it can be piped to a favorite editor). An application accesses the SQLite DB through library calls. A certain amount of access at the shell prompt is available via the sqlite utility. > Networking should definitely be a higher priority. Thinking of a networked multi-position station setup, each position's computer having Tlf using an SQLite DB could be less error prone with the potential for multiple entries from the other positions arriving nearly simultaneously and the local station wanting to read the log for previously worked callsigns, etc. SQLite appears to be able to manage that with ease whereas keeping a flat file in sync internally could be a problem. I don't have any empirical data to back this up, but my thought is that once a log file were to exceed a few thousand entries that SQLite would probably have the performance edge even if the log is kept in a single flat table. Food for thought. 73, Nate, N0NB -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819
signature.asc
Description: PGP signature
