View Issue Details

IDProjectCategoryView StatusLast Update
00035373 - Current Dev ListMaintenancepublic2019-11-01 10:27
ReporterK7ZCZAssigned To 
Status newResolutionopen 
Product Version6.6.0.237 
Target VersionFixed in Version 
Summary0003537: Logbook data is poorly structured
DescriptionAside from the related issue, the Logbook struggles with the clear management of data in several formats. It's obliged to take data from several sources -- ADIF, Cabrillo, XML, and so on -- and store them in its own native format.

This challenge is poorly solved. In particular, the Logbook largely uses pairs of synchronized name/value arrays to represent records. These arrays are simply lists of strings, correlated so that the index of a field name in one array matches the index of a field name in another. To find a value, the name array must be searched until the field name is found, then the corresponding index referenced in the value array. Operations that involve lots of rows end up sharply O(n^2) for time complexity because of the inner loops over each field multiplying their effect on the large number of rows.

A map would be a far more appropriate data structure for this application, as linear searhces wouldn't be necessary. Further, instead of using strings as keys, integers could be used instead; this would be faster and require less memory. And individual structures (and sets of integer identifiers) could be adopted for each different data format. One structure represents ADIF records, one Cabrillo, one for native Logbook data, and so on ... making different C++ types for different representational types would make the code clearer and more efficient. A helper object (or individual memober functions) would be provided to implement translations, centralizing the code and avoiding the copy-and-paste clutter that permiates the code today.
TagsNo tags attached.
TestingNot Started


There are no notes attached to this issue.

Issue History

Date Modified Username Field Change
2019-11-01 10:27 K7ZCZ New Issue