The ability to import into the database has been one of the most consistently requested features over RCLogbook’s lifetime. It has also been one of the more tricky ones to get right. While it amounts to a line in the change log, there was a huge amount of new code needed to do this (both real functional code as well as unit tests to try to exercise it). Time wise, this single feature has taken up the bulk of the development effort since 3.0.2 was released last year.
Interestingly, 3.5.0 is not the first time RCLogbook has had an import function. There have been several earlier attempts that were pulled out of releases for various reasons. What made the feature stick this time around was a conscious effort on my part to limit the scope and usage models for the function.
Early versions tried to support general edits to the database. This is difficult to do in a bullet-proof fashion due to (among other things), the amount of internal state in the database that the user never sees. Expecting the user to correctly edit this state and maintain internal consistency was a huge stumbling block. As soon as you admit that the user is not going to always do the right thing, the code absolutely needs to be bullet-proof and, as ancient mariners used to say, “Here be dragons…”.
On the 3.5 implementation, I stepped back to look at what user’s really needed. Most of the requests for import were along the lines of “I have a bunch of logs from <insert_old_logging_solution_here> and would like to get them into RCLogbook”. As a result, the 3.5 implementation focuses more on batch-type adds and edits. This does not provide a complete solution, but is one of those cases where a partial solution covers 90% of the real-life use cases.
Once the usage model was limited, many of the challenges that earlier implementations faced became far easier to deal with.
