Jump to content

Suggested update to the PQ selection criteria


W8TTS

Recommended Posts

Currently when setting up the selections for doing Pocket Queries you can only select on the Placed Date. Would it be possible to add the same selection criteria using the Published Date. Maybe being mutually exclusive by using a drop down menu where you could pick either the Placed Date or the Published Date.

 

The reason behind this is that some caches are placed a long time before they're published, and when selecting a Placed Date in the "last week" and the cache was places two weeks prior to it's Published Date it would be missed by the PQ. It would just be better to be able to select on the Published Date using the "last week", "last month", or "last year" options.

Link to comment

Hmm. That might be something worthwhile doing. It's already doable with one of the API's. And, knowing data base structure, not an impossible task to accomplish. :P I know that not all caches have a Published Log in their logs, so with those just assume the Place Date is the Publish Date, but if there is a Publish Log, use that log date as the Publish Date. Then we could have a truly usable date selection.

Link to comment

This would be a good idea if the published date was stored in the cache details table. Unfortunately, it is not, and thus this is not an easy change.

 

It wouldn't work for caches published before there was a "Published" log type but wouldn't changing "select * from cache" with "select c.*, cl.logdate from cache c, cachelog cl where cl.cacheid = c.cacheid and cl.logtype = 'Published'" provide what you need? (Obviously with specific names changed as appropriate)

Link to comment

Sure, it is possible to create a SQL query that would return the needed information. However, the call to the logs table is a very expensive one. On top of that, the PQ page would need an overhaul to include this change. This is what I meant by "not an easy change". I'm telling you up-front that there is not a reasonable chance that this would be implemented anytime soon.

Link to comment

What I'm saying is, that with a good DB it's a no brainer to add additional fields, and propagate the necessary information into the field. No need to read the logs except once as the Publish Date or Placed Date, if no Published Log, is propagated into the appropriate DB field.

Link to comment

"in the plans" - That's great news!

 

I was just going to say... what about, for the time being, an API call that will retrieve the requested information from a single cache? ie, What's the published date of GCXXX? (& if no publish log, then the first find log date; or even have that flag as a returned value)

 

Currently, it would 1) reduce the number of repeated {load log batch...load log batch...etc...no more logs} API requests, and 2) if set to use one API call each time from the daily limit, it'd be no more taxing than other more significant queries.

 

I can't wait for the publish date to be made available. The "Placed" date can be edited, moved, and be completely irrelevant... there was one local puzzle cache that had a ridiculously old placed date... and, I just found this (neat) themed traditional dated 1963 GC4T79R.

 

Published date is much more applicable to caching than 'Placed' date which isn't even a reliable piece of data. :P

Link to comment

Sure, it is possible to create a SQL query that would return the needed information. However, the call to the logs table is a very expensive one. On top of that, the PQ page would need an overhaul to include this change. This is what I meant by "not an easy change". I'm telling you up-front that there is not a reasonable chance that this would be implemented anytime soon.

 

I can assure you that getting published date information into the cache DB is in the plans. Once that happens, this request can be much more easily implemented.

 

If the change is going to be done I agree it would make more sense to add the field to the cache table and make it a one-off process to back-fill it, rather than running the same query repeatedly.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...