in reply to Re: CGI.pm: Want your query_string() sorted or unsorted?
in thread CGI.pm: Want your query_string() sorted or unsorted?

Thanks. I rarely use "Vars" any more in favor of param(), but I agree it sounds like it could be a good fit here, in combination with a hash comparison function.

<thinks>

I'm recalling that the other piece of wanting this is that the query strings will stored in a database column, and I want them in a canonical form for that, so that two identical queries in a different order will be represented the same.

For that, it sounds like I really do need a "sorted_query_string()" method, which I could supply as a plugin or new method to CGI.pm

Thanks to everyone for the feedback!

Mark Stosberg

  • Comment on Re^2: CGI.pm: Want your query_string() sorted or unsorted?

Replies are listed 'Best First'.
Re^3: CGI.pm: Want your query_string() sorted or unsorted?
by JavaFan (Canon) on Aug 13, 2009 at 11:53 UTC
    I'm recalling that the other piece of wanting this is that the query strings will stored in a database column, and I want them in a canonical form for that, so that two identical queries in a different order will be represented the same.
    That sounds like a database design disaster. Why not store the individual items of the query string as columns?
[reply]
      Storing query string as a key is useful if you are using a database to reply smartly with HTTP status 301/302/307 (redirect) or 407s (gone) instead of bare 404s (not found).
[reply]
      In this case, the query string represents a "saved search", and the design has worked fairly well over time. One complication here is that some of the search values have multiple keys. If we were to use Codd's third normal form, we wouldn't have just one row per search, but a whole collection of table rows.

      There are definitely other cases and future cases where I could consider putting each search value it's own database column.

      Mark Stosberg

[reply]

In Section Seekers of Perl Wisdom