http://qs1969.pair.com?node_id=788221


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

It's a long time since I used QUERY_STRING or CGI.pm, but isn't the only worthwile feature of CGI.pm the fact you don't have to bother with QUERY_STRING yourself? And if I really want to compare QUERY_STRINGS, I could just call the Vars method and compare the resulting hashes. There are modules out there that will compare hashes for you.
  • Comment on Re: CGI.pm: Want your query_string() sorted or unsorted?

Replies are listed 'Best First'.
Re^2: CGI.pm: Want your query_string() sorted or unsorted?
by markjugg (Curate) on Aug 13, 2009 at 11:50 UTC
    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

[reply]
      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