Recycling cache IDs

[+Sissy-n-CR]

In an effort to slow the progression towards "rollover" would recycling cache IDs be feasible?

 

Take all archived and/or unapproved cache pages without any logs and put them in a que. Give cache owner a month to reclaim this defunct ID. Otherwise, wipe the record and start over again.

 

If there aren't any records linked to it otherwise, then there is no reason to unlink it from the original owner and give it to someone else.

 

Also, you could encourage owners to recycle unapproved or logless archived caches.

 

How hard would it be to search those caches out and send emails encouraging them reuse that old cache ID?

 

CR

 

[Elias]

quote:

---

Originally posted by Sissy-n-CR:

In an effort to slow the progression towards "rollover" would recycling cache IDs be feasible?

---

I'm not sure I understand the advantage in doing this. Is this to keep the hex encoding we use now or possibly as an alternative to the hack I posted here?

 

quote:

---

How hard would it be to search those caches out and send emails encouraging them reuse that old cache ID?

---

Technically, its pretty easy. But it just seems a little aggressive to me.

 

-Elias

[+Sissy-n-CR]

quote:

---

Originally posted by Elias:

 

I'm not sure I understand the advantage in doing this.

---

 

It's only to push down the inevitable rollover further down the road. A byproduct is the advantage of not having junk records.

 

I pointed out yet another scheme for waypoints in another thread--the 8-digit-hex-with-trucating-for-6-digit-GPS-units scheme.

 

CR

 

[+Markwell]

Since this is just a stop-gap measure, it's kind of like saying we can postpone this Y2K problem by rolling the dates back to using each Feb 29 of the non-leap year days. I'd prefer a longer term solution like Elias is suggesting.

[+Sissy-n-CR]

quote:

---

Originally posted by Markwell:

Since this is just a stop-gap measure, it's kind of like saying we can postpone this Y2K problem by rolling the dates back to using each Feb 29 of the non-leap year days. I'd prefer a longer term solution like Elias is suggesting.

---

 

Not saying this will eliminate the problem. Just saying it could push back the rollover and give them more time.

 

The added benefit is eliminating the dead weight of unused cache_IDs. Why deal with dead weight when you can put them to use?

 

First you'd have to look at how many dead cache-ID are out there. A simple search for archived cache with no logs would have to be done. If a sufficient number comes back then it may be worth looking at it. I don't know the mechanics behind the scenes, but it seems to me you could clear those caches and set them into a que. The next time a person requests a cache_ID a recycled number would be issued instead of just adding 1 to the last number issued.

 

If you can gain a few thousand numbers with a couple hours work, would it be worth it?

 

I'm just saying a look at the cost/benefit might be worth it.

 

CR

 

[Elias]

quote:

---

Originally posted by Sissy-n-CR:

If you can gain a few thousand numbers with a couple hours work, would it be worth it?

---

The IDs are generated automatically by the database when a new record is inserted. So to do this would mean we'd have to take on the burden on of generating the unique IDs and making sure no two records get the same ID if inserted into the database at almost exactly the same time. It certainly could be done, but to reinvent SQL Server's auto-numbering functionality for a few thousand numbers really doesn't make sense.

 

-Elias

[+Sissy-n-CR]

quote:

---

Originally posted by Elias:

...to reinvent SQL Server's auto-numbering functionality for a few thousand numbers really doesn't make sense.

 

-Elias

---

 

Okay, it was just a thought.

 

CR

 

[Elias]

quote:

---

Originally posted by Sissy-n-CR:

Okay, it was just a thought.

---

It was a reasonable idea. We're always open to suggestions as its very possible we've missed or haven't thought of something. So feel free to keep 'em coming.

 

-Elias

[+Sissy-n-CR]

I emailed Elias another thought on recycling ID's and he said I should post it here for further discussion.

 

Here's the email:

quote:

---

On the subject of Recycling Cache ID's somebody closed the topic, but I have one more idea--one that won't be obsolete after rollover.

 

I don't know how many IDs fit the critiria of unapproved or archived without logs--caches that could easily be recycled--so I don't know if it worth it, but here goes.

 

It could actually be more usefull than just recycling IDs. People have mentioned a "This cache needs adoption" setting on logging a cache. It's for caches that seem to have been abandoned. The minutiae for determining when a cache is actually put on the list is not in the scope of this mail, though. What is, is the fact that unapproved and logless archived caches can be cleared and placed on this list as well.

 

Here is how I envision it.

 

When a person goes to the report-a-cache page, a link will be at the top saying something to the effect "Adopt a cache in your area" and a link

"Get older cache ID."

 

Clicking on the first link will bring up something like a search page giving the user the option to search for adoptable caches within a 50 mile radius. The user checks details of the adoptable caches in the area and chooses. The system assigns the cache to that person after review and it is removed from the list.

 

If the other link is selected, the system automatically searches the list for caches at a certain coordinates. The trick is that the recyclable ID's have their coordinates set to this same coordinate. The first ID that pops up is assigned and the report-a-cache page is simply refreshed with the cache ID.

 

If there were recyclable IDs, when refreshed the page might include a short message thanking them for using a recycled ID. If there wasn't then a message thanking them for checking, but there weren't any to recycle.

 

Alternatively a flag could be used to selectively put the link on the page when there are recyclable IDs and remove it when there aren't.

 

This scheme could be implemented and brought online before there are any actual adoptable caches placed on the list so IDs can start to be recycled. The minutiae of placing caches on the adoptable list could be hammered out later with the owner option of placing it on the list himself.

 

Just a thought!

 

CR

 

---

 

Call it an attribute of a simple mind, but sometimes a problem gets stuck in my head until I figure it out. The problem I see to the dead weight of unused caches pages and wasted cache_IDs.

 

The above solves the problem of wasted IDs and assigning the numbers. Plus, being able to roll the adoptable caches into the assignment adds a useful feature to the site. It allows caches that may otherwise be simply taken out of play to be adopted and continue.

 

Granted, it's a major feature, but worth it, IMHO.

 

CR

 

[+Mopar]

Even if its do-able, is it really worth all that manual labor to recycle a weeks worth of new cache IDs?

 

Tae-Kwon-Leap is not a path to a door, but a road leading forever towards the horizon.

[+ClayJar]

(First, let me say that active-but-abandoned cache adoption is a very nice thing, and we in Louisiana have done that several times with excellent results.)

 

Recycling cache IDs is a very bad idea. (Not only that, but it is, in fact, quite literally WRONG.)

 

Cache IDs are serial numbers. Cache IDs are primary keys. Cache IDs are monotonically increasing. If you don't understand monotonically increasing primary keys, I would be more than happy to locate a nice book on databases for you. In fact, I'll buy one and ship it to you personally! (E-mail me an address and I'll get one out to you ASAP.)

 

Anyway, trying to solve the theoretical exhaustion of waypoint names by changing cache IDs from a monotonically increasing primary key is, by definition, wrong. You can change the waypoint naming scheme; you can add a new field; you cannot recycle a monotonically increasing primary key.

[+Sissy-n-CR]

quote:

---

Originally posted by ClayJar:

If you don't understand monotonically increasing primary keys...

---

 

I don't. But if you're talking about taking the cache_ID and creating a new record. That's not what I envision.

 

I envision simply clearing the fields of the defunct cache and letting someone else have it. Same record, but cleared and new info put in it's place. I understand there will be hooks to other records, but they will be minimum as these caches have never be logged.

 

It's more like adopting a cache that never was.

 

If you can be brief as to why it's not a good idea, please post it here. I don't have time to read volumes about esoteric DB schemes and processes--I'd rather be caching.

 

CR