Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling

Re: Super Search Sort Order

by iguanodon (Priest)
on Feb 03, 2003 at 18:13 UTC ( #232338=note: print w/replies, xml ) Need Help??

in reply to Super Search Sort Order

You've got my vote, literally.

Would we not find more recent and possibly more pertinent answers if we just reversed the search order..?
I think so. I've used Super Search recently to find nodes that I knew were only a few days or weeks old, but all I could remember was a keyword.

How about letting the user decide? The Newest first -or- Oldest first option is there, but disabled.

Replies are listed 'Best First'.
Re: Re: Super Search Sort Order
by AcidHawk (Vicar) on Feb 03, 2003 at 18:34 UTC

    AS far as I understand letting the user decide "Newest first -or- Oldest first" requires a large amount of re-work i.e. coding etc...

    The options are there but are disabled. I am merely looking for a (What I think is a) short term solution, which would make many monks' searches a little more productive and if my thinking is correct more results would be reached in less queries thereby putting less load on the database.

    Of all the things I've lost in my life, its my mind I miss the most.
      I understand letting the user decide [...] requires a large amount of re-work

      I have no idea where you got that impression. I said:

      I'd like to support searching "newest nodes first" but the MySQL optimizer will likely fight me on this.
      which has nothing to do with the amount of work involved.

      Switching from always oldest first to always newest first is only a little less work than letting you choose between the two. The problem is that sorting on descending keys doesn't optimize very well in this version of MySQL (the documentation describes how this is caused by NULL values, but we don't have or even allow NULL values for that field so that shouldn't apply but testing shows that it certainly does).

      So there is a moderate amount of work to put in support for searching most recent nodes first. But there is also a good chance that after that work is done the option will often be useless because the optimizer won't work well when you select that option and so your search will not be done.

      So it is just a matter of someone finding the time. It isn't a priority because super search is very useful (at least to me) as it is, the work might well not pay off anyway, it isn't as much fun as some other items, and there are more important problems to deal with (to name a few reasons).

                      - tye

        Thank you for setting me straight and pointing to the more precise issue. Appologies if I mis-interpreted (tye)Re2: Newest Super Search, but I understood

        Well, I tried to design it so that much of the time you can just fill in what you are searching for in that first box and then hit the button. But there needs to be some major work on how the results are presented after that.

        to mean that considerable work would be required. I do not have an understanding of the MySQL optimizer and this is probably what created that impression.

        On another note altogether, is there documentation on how yougo about testing patches or code for PerlMonks? If some-one found some spare time to look at possibly patching some of the PerlMonks code.. where could they start..?

        Of all the things I've lost in my life, its my mind I miss the most.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://232338]
[Corion]: A good morning and weekstart to you too, Discipulus!

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (5)
As of 2018-06-25 07:16 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (126 votes). Check out past polls.