OK, this is a harder problem to fix than it seems at first.
As a summary, I keep a record of all alerts on SOTAwatch in a database, pulled down every 10 or 15 minutes (I can’t remember exactly, but it’s not that important so I won’t look it up
). My current approach is to remove all alerts from the table, and repopulate with the alerts currently listed on SOTAwatch. Thus, the table is a direct copy of the SOTAwatch alerts page, in a format RBNHole can handle, minus excluded alerts and operators that have opted out.
The S+/S- is implemented using a start/end time window calculated from the SOTAwatch alert time and any S+/- bits in the comment string. The obvious solution is to not remove all the alerts from the table at the beginning, simply remove those alerts for whom the end time is earlier than now. Easy. Looks like one case to handle, which is to not insert alerts into the table that are already there (avoid duplicates).
This is relatively easy, except for the fact you also have to handle the fact that people can modify alerts. This increases the cases we need to handle. And there’s a few tricky ones.
Case 1: Alert time the same, operator the same, new summit code. Straightforward, update the summit code, continue.
Case 2: Alert time the same, operator the same, comment changed. Straightforward, check the comment for “S+/S-” and update start/end times accordingly.
Case 3: Alert time the same, operator the same, comment now contains “NoRBNHole” etc. Now we need to delete the alert from the table. Still relatively straightforward, but some extra handling required as usually alerts don’t make it down to this point if they’ve been excluded. Nothing insurmountable, but we’re now up to about 5 times the code we initially thought we needed.
Case 4: Operator changes alert time. Now we run headlong into the first brick wall. Let’s assume I’ve posted an alert for 1 Jan 2017 for summit VK3/VC-030 at 0000 hrs. I’ve also got an alert for 1 Dec 2016 for the same summit. Got to maximise those points! I suddenly realise I won’t make it on 1 Jan because I’m going away, so I change to 2 Jan 2017. How do I identify this alert change? My table contains an alert with my original time. I could look for same operator, same summit, but there’s two alerts for that summit. Which was changed? Oh, I can check to see if either of those is duplicated already, but now I’m not processing row-by-row, I’m getting into deeper SQL query territory. Lots more complexity now.
Of course, on SOTAwatch (and in my DB) the primary key is a separate alert ID, which isn’t available to RBN Hole to identify modified alerts by. I can talk to Jon about that.
Case 5: Operator deletes an alert. Now I’m seriously screwed. The alert is gone, and I have no idea it’s gone. But, I have eternal faith in the power of computers to fix problems. I’ve got this. I can go through and scan my list of alerts for any that are in the database but aren’t in the list and assume they’re deleted. Which, if you’re still following, is functionally the same as (and 10x more complex than) deleting the entire table and repopulating - my current approach.
The real kicker is you have to delete alerts; it’s a non-negotiable, as someone will get spotted if they abort due to weather, stay home, call CQ and get picked up by the RBN. What follows is much irate (and I guess justifiable) complaining on the reflector.
Case 6: Alert disappears from SOTAwatch after 36 hours: this is the original problem. This is functionally equivalent to Case 5. The alert disappears. Did an operator delete it, or did SOTAwatch hide it? I don’t know, and by now that bottle of scotch is looking tempting.
In short, I’m reverting any changes I’ve made here and will go back to the existing approach for now. Longer term, I’ll work with Jon on getting the SOTAwatch API to the point where I can pull alerts with an identifying string/ID and maintain a proper set of alerts.
In the interim, you can invert your logic, and rather than do a S+54, do an S-54 and alert later, or alert each day you intend to be out at 1200hrs and the intended summits you are going to approach with a S+12/S-12.