Jump to content

PQ changing with Sort on website view


ertyu

Recommended Posts

If I view the list of caches in a PQ on the website and then re-sort the view based on an alternate parameter such as Favourite Points, I get a different list of caches than actually appears within the PQ.

http://www.geocaching.com/seek/nearest.aspx?pq=XYZ&sortdir=asc&sort=fav

 

My guess would be that a fresh database query is taking place to generate the list according to the sort criteria. And since there are far more caches available in the database than the PQ allows, sorting by different criteria acquires a different set of the top 1000 caches.

 

While this certainly could be a useful feature to have when creating the PQ (the ability utilize a different sort than nearest to optimize the caches collected by a PQ) it isn't what the PQ does and thus the website is replicating something entirely odd.

Link to comment

This is expected behavior if your PQ is maxing out the number of caches it will return. Let's say that you have your PQ returning 1000 caches from a given origin, but its radius is 100 miles and there are actually 5000 caches that meet the PQ criteria in that radius. This means that 4000 matching caches have to be thrown out. Initially you will likely get the 1000 closest caches to the origin, but as soon as you sort the preview for Favorites, you are sending a new query to the database. You are then not asking for the 1000 closest, but the 1000 with the highest number of Favorites among the 5000 available that match the PQ criteria. These are not likely to be the same subset that were originally returned.

 

The best way to avoid this is to prevent your PQ from hitting the maximum.

Link to comment

This is expected behavior if your PQ is maxing out the number of caches it will return. Let's say that you have your PQ returning 1000 caches from a given origin, but its radius is 100 miles and there are actually 5000 caches that meet the PQ criteria in that radius. This means that 4000 matching caches have to be thrown out. Initially you will likely get the 1000 closest caches to the origin, but as soon as you sort the preview for Favorites, you are sending a new query to the database. You are then not asking for the 1000 closest, but the 1000 with the highest number of Favorites among the 5000 available that match the PQ criteria. These are not likely to be the same subset that were originally returned.

 

The best way to avoid this is to prevent your PQ from hitting the maximum.

 

This shouldn't be the expected behaviour. It makes no sense to present a list of caches in a PQ that isn't the list of caches in a PQ.

Link to comment

 

This shouldn't be the expected behaviour. It makes no sense to present a list of caches in a PQ that isn't the list of caches in a PQ.

 

It makes sense if you understand database queries. The initial preview that is returned is a live search using the criteria you set up in the PQ, but - and this is important - it is not the PQ itself. Once you change the sorting, you are submitting a different set of criteria. For it to only show what is in the PQ at that point, we would have to develop a completely new and different search/display mechanism that was not universal but only worked for PQ preview.

Link to comment

This shouldn't be the expected behaviour. It makes no sense to present a list of caches in a PQ that isn't the list of caches in a PQ.

It makes sense if you understand database queries.

I think that's where the confusion comes from. If one needs to be a database expert to understand the operation of the website, I have to say the site design is flawed. I understand why the site does what it does, but it still isn't what I would call "expected behaviour". Having the list sort the same results in a different order is what I would call expected.

Link to comment

I think that's where the confusion comes from. If one needs to be a database expert to understand the operation of the website, I have to say the site design is flawed. I understand why the site does what it does, but it still isn't what I would call "expected behaviour". Having the list sort the same results in a different order is what I would call expected.

 

That's why I explained that the solution would mean developing entirely new functionality. The current solution may not be ideal from an outside perspective, but it allows us to use existing code to accomplish the basic need and is better than no preview at all.

Link to comment

This is a basic programming cop out. Because the expected behaviour requires more work it wasn't done. What's left is broken and confusing.

 

I think it should either be fixed or prevented from happening. Either disable the filtering ability or flag the display to indicate that the list no longer represents the contents of the PQ until it can be fixed properly.

 

When the title says "Running Pocket Query: XYZ", I expect the contents to be that PQ. Anything else is a horrible UI.

Link to comment

Remember, you can work around this issue by preventing your PQ results from exceeding the cap on the number of returned results.

Doing this is also friendly to cachers everywhere as the database and servers will be doing a bit less work looking for "too many" caches in the first place.

Link to comment

Remember, you can work around this issue by preventing your PQ results from exceeding the cap on the number of returned results.

Doing this is also friendly to cachers everywhere as the database and servers will be doing a bit less work looking for "too many" caches in the first place.

 

VERY good point.

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