Jump to content

BUG (I think): Sorting PQ


redwoodkestrel

Recommended Posts

I've noticed today that when I preview a pocket query I've made via the map (so a radius around a point) in list mode, the first list that comes up is, in fact, my pocket query, displaying all 1000 caches that were within the correct radius on the map, sorted (I assume) by distance from the original center point - whatever the default listing order is when you preview a PQ. However, as soon as I try to sort that list, I still have 1000 caches, but they're from much farther out than my initial radius - so it's not the original 1000 caches, but 1000 caches pulled from a much larger area.

 

So, for example, I'm interested in finding caches in my home area that are of a few D/T combinations. So I run a PQ centered on my home coordinates, returning 1000 caches. I preview that list - all looks good, they're all within that initial radius from my home coordinates - about 10 miles. Then I click the "D" in the "D / T" header to sort by difficulty, so I can look specifically for caches nearby that have the D/T combinations I'd like. All of a sudden I have caches in my list that are from way beyond my home area (100+ miles) that were not in my initial PQ. It still only displays 1000 caches, but it's not the original 1000 in my PQ.

 

The same thing happens if I sort by "Placed" or "Last Found" or any other sortable header.

 

I assume this is a bug? Or are pocket queries really only able to be previewed in the default list that comes up, not sortable?

Link to comment

From another post I made regarding this:

 

This is technically not a bug. The PQ preview is not truly a preview of the PQ results, but a database search that matches the search criteria of the PQ. The disconnect occurs if your PQ is set to return more caches than the PQ can hold (e.g., more than 1000 caches in your case). When this happens, the initial preview matches what you will get in your PQ. However, if you sort by Favorite Points, then you are changing the call to the database. It is no longer a search for the caches closest to home, but a search for the caches with the highest FP count within the PQ's specified radius.

 

The way to avoid this issue is to set your PQ criteria (usually radius) such that it returns slightly fewer caches than maximum. That way, when you sort it will still still be pulling from the same subset of caches.

Link to comment

If you are looking for a specific D/T why not filter in the PQ so only those return?

 

I started out initially looking for caches placed on certain dates. Since you can't filter and return a PQ for date without year, I figured I'd just sort by date placed and check those few specific dates I'm still looking for through the years. So while the sort would list the caches placed by date and year, I could just search through the pages and find those few dates each year that I'm interested in.

 

From another post I made regarding this:

 

This is technically not a bug. The PQ preview is not truly a preview of the PQ results, but a database search that matches the search criteria of the PQ. The disconnect occurs if your PQ is set to return more caches than the PQ can hold (e.g., more than 1000 caches in your case). When this happens, the initial preview matches what you will get in your PQ. However, if you sort by Favorite Points, then you are changing the call to the database. It is no longer a search for the caches closest to home, but a search for the caches with the highest FP count within the PQ's specified radius.

 

The way to avoid this issue is to set your PQ criteria (usually radius) such that it returns slightly fewer caches than maximum. That way, when you sort it will still still be pulling from the same subset of caches.

 

Great! Thanks for the help Moun10Bike - that's why I wasn't sure if it was really a bug or something I just didn't quite understand about the PQ preview. Glad to hear it's just me! :D I'll try running a new PQ now!

Link to comment

Still a BUG.

 

No, it's not - read Moun10Bike's explanation to my initial post. Set your PQ radius small enough that it returns just under 1000 caches and you can easily sort the PQ, keeping all the original caches that are returned.

 

Once I went back and tried it, it worked great! The only thing you may need to do is to keep tweaking the radius until you get just under 1000 caches - so don't schedule it to run (i.e., don't pick a day of the week) until you've got the radius figured out.

Edited by redwoodkestrel
Link to comment

Still a BUG.

 

No, it's not - read Moun10Bike's explanation to my initial post. Set your PQ radius small enough that it returns just under 1000 caches and you can easily sort the PQ, keeping all the original caches that are returned.

 

Once I went back and tried it, it worked great! The only thing you may need to do is to keep tweaking the radius until you get just under 1000 caches - so don't schedule it to run (i.e., don't pick a day of the week) until you've got the radius figured out.

 

It certainly is a BUG, just because you can work around it, doesn't mean it is not.

The software doesn't produce the expected result, that is a BUG.

 

Besides the explanation doesn't make a lot of sense to me either. It seems like it would be a simple tweak to use all the parameters of the PQ in the database query, not just some of them, to produce the web list, dropping one of them seems silly.

Edited by ertyu
Link to comment

Besides the explanation doesn't make a lot of sense to me either. It seems like it would be a simple tweak to use all the parameters of the PQ in the database query, not just some of them, to produce the web list, dropping one of them seems silly.

 

You are misunderstanding how a SQL query works. It IS using all of the parameters of the PQ in the database query. The problem is when the user is asking the PQ to return more results than are allowed by the PQ (in this case 1000). When the user then sorts, they are essentially saying to the query, "instead of capping caches based on proximity to the origin, cap it based on the number of Favorites" (or whatever else is being sorted on). This logically results in a different set of returned caches.

Link to comment

Still a BUG.

 

No, it's not - read Moun10Bike's explanation to my initial post. Set your PQ radius small enough that it returns just under 1000 caches and you can easily sort the PQ, keeping all the original caches that are returned.

 

Once I went back and tried it, it worked great! The only thing you may need to do is to keep tweaking the radius until you get just under 1000 caches - so don't schedule it to run (i.e., don't pick a day of the week) until you've got the radius figured out.

 

It certainly is a BUG, just because you can work around it, doesn't mean it is not.

The software doesn't produce the expected result, that is a BUG.

 

Besides the explanation doesn't make a lot of sense to me either. It seems like it would be a simple tweak to use all the parameters of the PQ in the database query, not just some of them, to produce the web list, dropping one of them seems silly.

 

Your definition of a bug is wrong. A bug is an unintended consequence of a change in programming. What you are talking about is a feature request. Just because it doesn't do what you want it to do does not make it a bug.

Link to comment

Your definition of a bug is wrong. A bug is an unintended consequence of a change in programming. What you are talking about is a feature request. Just because it doesn't do what you want it to do does not make it a bug.

Your definition of a bug is wrong. A bug is a behavior in the software that is unexpected or does not meet the requirements.

 

In this case the expected behavior is for the same caches to be returned regardless of the sort order.

 

Moun10Bike's explanation that the limit to 1000 caches is done after sorting so that you may have a different 1000 caches returned depending on whether or not you have sorted by favorite points does not mean this is not a bug.

 

Of course since this is a behavior of the way SQL handles a SELECT TOP or a LIMIT clause in the presence of an ORDER BY clause, the programmer may feel the software is working as expected. At that point, the developers may prefer to track any change internally as a feature request instead of as a defect, but it doesn't change the fact that to the user this is a bug.

Link to comment

Besides the explanation doesn't make a lot of sense to me either. It seems like it would be a simple tweak to use all the parameters of the PQ in the database query, not just some of them, to produce the web list, dropping one of them seems silly.

 

You are misunderstanding how a SQL query works. It IS using all of the parameters of the PQ in the database query. The problem is when the user is asking the PQ to return more results than are allowed by the PQ (in this case 1000). When the user then sorts, they are essentially saying to the query, "instead of capping caches based on proximity to the origin, cap it based on the number of Favorites" (or whatever else is being sorted on). This logically results in a different set of returned caches.

 

I understand how a database query works. And also that it should be a simple tweak to query the database with the 1000 limitation based on proximity and then re-sort based on the new sort criteria to maintain the logical presentation of caches that are present in the PQ.

Link to comment

I understand how a database query works. And also that it should be a simple tweak to query the database with the 1000 limitation based on proximity and then re-sort based on the new sort criteria to maintain the logical presentation of caches that are present in the PQ.

 

You are being deliberately obstinate at this point. Since the OP's question has been answered, and the thread is in danger of being hijacked, I'm closing it.

Link to comment
Guest
This topic is now closed to further replies.
×
×
  • Create New...