View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003537||3 - Current Dev List||Maintenance||public||2019-11-01 10:27||2019-11-01 10:27|
|Target Version||Fixed in Version|
|Summary||0003537: Logbook data is poorly structured|
|Description||Aside 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.
|Tags||No tags attached.|