Change History

Let me first explain how GetOldest() work right now.

Simply put, it's a [code]SELECT * FROM geocaches ORDER BY hidden, cacheId LIMIT x[/code].

In other words, for those who don't speak SQL. It fetches [i]limit[/i] geocaches ordered by the hidden date, and then the cache-id.

The problem here is that the max limit is 100 (actually it's 1000, newly changed). Since a challenge must include archived geocaches this causes an issue. If the challenge is to log 20 of the oldest 100, it might be that not all active caches are included. First for the reason that there might be too many archived caches, pushing the active ones outside the limit. It can be assumed that we actually want the 100 oldest that are active, and those older than the newest one. The second issue is that it might be expected that all geocaches from 2004-01-02 is included if one of them are. They are not, since we are cutting hard on the limit.


I have now made a new implementation, which is not released yet. I am looking for feedback.

The new approach is to first figure out the oldest hidden date that falls into the filter. In SQL it's more like [code]SELECT MAX (hidden) FROM geocaches ORDER BY hidden LIMIT x[/code]

And then we make a second run which is then [code]SELECT * FROM geocaches WHERE hidden <= maxHidden ORDER BY hidden[/code] (no limit).


So, the question is. Is there anyone who think this approach will be a problem with any current scripts? It seems like some checkers are broken due to an API that has unexpected behaviours. As I see it it can only fix things, though it might change things as well.

If there are any objections, I would like to hear the argument. Based on that we can decide if we will move all current scripts to an obsolete API method or I can just overwrite the current one, or maybe keep both in parallell.

Let me first explain how GetOldest() work right now.

Simply put, it's a [code]SELECT * FROM geocaches ORDER BY hidden, cacheId LIMIT x[/code].
In other words, for those who don't speak SQL. It fetches [i]limit[/i] geocaches ordered by the hidden date, and then the cache-id.

The problem here is that the max limit is 100 (actually it's 1000, newly changed). Since a challenge must include archived geocaches this causes an issue. If the challenge is to log 20 of the oldest 100, it might be that not all active caches are included. First for the reason that there might be too many archived caches, pushing the active ones outside the limit. It can be assumed that we actually want the 100 oldest that are active, and those older than the newest one. The second issue is that it might be expected that all geocaches from 2004-01-02 is included if one of them are. They are not, since we are cutting hard on the limit.


I have now made a new implementation, which is not released yet. I am looking for feedback.

The new approach is to first figure out the oldest hidden date that falls into the filter. In SQL it's more like [code]SELECT MAX (hidden) FROM geocaches ORDER BY hidden LIMIT x[/code].


And then we make a second run which is then [code]SELECT * FROM geocaches WHERE hidden <= maxHidden ORDER BY hidden[/code] (no limit).


So, the question is. Is there anyone who think this approach will be a problem with any current scripts? It seems like some checkers are broken due to an API that has unexpected behaviours. As I see it it can only fix things, though it might change things as well.

If there are any objections, I would like to hear the argument. Based on that we can decide if we will move all current scripts to an obsolete API method or I can just overwrite the current one, or maybe keep both in parallell.

Let me first explain how GetOldest() work right now.

Simply put, it's a [code]SELECT * FROM geocaches ORDER BY hidden, cacheId LIMIT x.
x[/code].
In other words, for those who don't speak SQL. It fetches [i]limit[/i] geocaches ordered by the hidden date, and then the cache-id.

The problem here is that the max limit is 100 (actually it's 1000, newly changed). Since a challenge must include archived geocaches this causes an issue. If the challenge is to log 20 of the oldest 100, it might be that not all active caches are included. First for the reason that there might be too many archived caches, pushing the active ones outside the limit. It can be assumed that we actually want the 100 oldest that are active, and those older than the newest one. The second issue is that it might be expected that all geocaches from 2004-01-02 is included if one of them are. They are not, since we are cutting hard on the limit.


I have now made a new implementation, which is not released yet. I am looking for feedback.

The new approach is to first figure out the oldest hidden date that falls into the filter. In SQL it's more like SELECT MAX(hidden) FROM geocaches ORDER BY hidden LIMIT x.

And then we make a second run which is then SELECT * FROM geocaches WHERE hidden <= maxHidden ORDER BY hidden (no limit).
The new approach is to first figure out the oldest hidden date that falls into the filter. In SQL it's more like [code]SELECT MAX(hidden) FROM geocaches ORDER BY hidden LIMIT x[/code].

And then we make a second run which is then [code]SELECT * FROM geocaches WHERE hidden <= maxHidden ORDER BY hidden[/code] (no limit).


So, the question is. Is there anyone who think this approach will be a problem with any current scripts? It seems like some checkers are broken due to an API that has unexpected behaviours. As I see it it can only fix things, though it might change things as well.

If there are any objections, I would like to hear the argument. Based on that we can decide if we will move all current scripts to an obsolete API method or I can just overwrite the current one, or maybe keep both in parallell.

Let me first explain how GetOldest() work right now.

Simply put, it's a SELECT * FROM geocaches ORDER BY hidden, cacheId LIMIT x.
In other words, for those who don't speak SQL. It fetches [i]limit[/i] geocaches ordered by the hidden date, and then the cache-id.

The problem here is that the max limit is 100 (actually it's 1000, newly changed). Since a challenge must include archived geocaches this causes an issue. If the challenge is to log 20 of the oldest 100, it might be that not all active caches are included. First for the reason that there might be too many archived caches, pushing the active ones outside the limit. It can be assumed that we actually want the 100 oldest that are active, and those older than the newest one. The second issue is that it might be expected that all geocaches from 2004-01-02 is included if one of them are. They are not, since we are cutting hard on the limit.


I have now made a new implementation, which is not released yet. I am looking for feedback.

The new approach is to first figure out the oldest hidden date that falls into the filter. In SQL it's more like SELECT MAX(hidden) FROM geocaches ORDER BY hidden LIMIT x.

And then we make a second run which is then SELECT * FROM geocaches WHERE hidden <= maxHidden ORDER BY hidden (no limit).


So, the question is. Is there anyone who think this approach will be a problem with any current scripts? It seems like some checkers are broken due to an API that has unexpected behaviours. As I see it it can only fix things, though it might change things as well.

If there are any objections, I would like to hear the argument. Based on that we can decide if we will move all current scripts to an obsolete API method or I can just overwrite the current one, or maybe keep both in parallell.