Jump to content
Sign in to follow this  
Followers 3
sookoll

BUG: roll back wrong TB drop off

Recommended Posts

At first I drop off correct TB, when I created log. Then I change this log and after that, wrong TB was listed in cache inventory. After deleting trackable log entry, it still remanis on cache inventory. I edit cache log and drop off correct TB. Now they both are listed in cache inventory and I don't have any TB in may hand, but first TB should be. So I can't drop it off anymore. What the heck?

Share this post


Link to post

Not a bug - a feature. ;) Deleting trackable logs does NOT undo the action!

 

Retrieve the bug you still have, as if you just picked it up.

  • Upvote 1
  • Helpful 1

Share this post


Link to post
Posted (edited)

Can't see how this is a feature... If I delete the log and trackable page status is correct, that I retrive it from first cache but geocache page shows, that this TB is in second cache where it actually isn't, then it is a bug. So I have to retrive it from second cache, where it actually never was. Go figure...

Edited by sookoll
edit

Share this post


Link to post
1 hour ago, sookoll said:

Can't see how this is a feature... If I delete the log and trackable page status is correct, that I retrive it from first cache but geocache page shows, that this TB is in second cache where it actually isn't, then it is a bug. So I have to retrive it from second cache, where it actually never was. Go figure...

I think I'd call it a "feature", i.e., something that doesn't quite make sense but still follows an alternative logic that can't really be said to be wrong. I know nothing about the implementation, but my guess is that it's not the way it is because anyone wanted it that way, it's just this way because there's no information in the database to tell the software where the TB was before it was dropped in the cache. You might be able to imagine a heuristic for a simple case, but once I start thinking about the wealth of possible scenarios, I can see there's no good way to implement deleting a log as restoring a previous state. For example, what if *two* logs are deleted? And does it matter which order the logs are deleted? And what about the find? If I was mistaken about which cache I found and I delete the find log, it would make sense for me to expect any TB drops to also be deleted, but the implementation starts to get hairy.

 

Oh, well, and in addition, the most common reason to delete a drop log is to hide the action that got the TB into the cache. Fixing a mistaken TB drop is probably only the second most common reason.

 

All that is by way of agreeing with you that it's surprising and perhaps even illogical that deleting a drop log doesn't undo the drop, but I think there are good reasons that it's that way.

Share this post


Link to post
On 1/7/2019 at 10:58 PM, sookoll said:

Can't see how this is a feature... If I delete the log and trackable page status is correct, that I retrive it from first cache but geocache page shows, that this TB is in second cache where it actually isn't, then it is a bug. So I have to retrive it from second cache, where it actually never was. Go figure...

 

"Oops, I dropped it into the wrong cache" is one reason to delete a log on a trackable, but it's not the only reason.  I'm OK with the system not being designed to presume things.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
Followers 3

×