[BUG]: stray dive-sites after parsing ssrf/xml

Dirk Hohndel dirk at hohndel.org
Wed Nov 8 07:15:57 PST 2017


> On Nov 8, 2017, at 3:04 AM, Jan Mulder <jlmulder at xs4all.nl> wrote:
> 
> Did some analysis on my logbook (that I have stored as a local git repo, so not an ssrf/xml). I found approx. 10 dive sites that had 0 dives connected to it. They all seemed the result of misspelling of the dive site name, and correcting it later.
> 
> On 07-11-17 21:50, Lubomir I. Ivanov wrote:
>> in MapWidgetHelper::reloadMapLocations() we do not skip such and
>> markers are added for them.
>> judging from the Marble port that i did, we had the same behavior there.
>> also, not exactly sure how this ended up happening, but i need some
>> decision making here:
>> - should we discard these at the parsing stage?
> 
> Not sure about this one. When we make shure that we never save dive sites without dives attached to it (see below), there is no need to add any logic for this.
> 
>> - should we discard this at the saving stage?
> 
> The fix for this is easy, and it seems wise to implement this (I will create a PR for review). Why would we keep carrying around site data that is not related to any dive? Obviously, this introduces the issue that you cannot "clone" dive sites any more to attach your dives later to it, but I do not see that as a relevant use case, as it involves manual editing of the logbook storage (as we do not have true dive site management).

I honestly thought that we already did that. I was wondering if we had a discussion of this subject on the mailing list but my Google-Fu didn't come up with anything specifically about this.
To me it seems to make sense that we'd discard sites that aren't connected to dives. Subsurface is a dive log, not a dive site log.

And yes, simply not saving them does seem to address all of the issues.

/D


More information about the subsurface mailing list