Some punctuation breaks search+discussion
A related discussion should talk about trapping search terms that will throw up similar SQL errors. For example: Search term in same setup of "`&$" throws SQL error:
ActiveRecord::StatementInvalid: Mysql::Error: #42000You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'OR OR ) and t.trash='f' ORDER BY t.updated_at desc LIMIT 50 OFFSET 0)' at line 1: (select t.* from cards t join revisions on revisions.id=t.current_revision_id where ( OR OR ) and t.trash='f' ORDER BY t.updated_at desc LIMIT 50 OFFSET 0)
{"match":"_keyword", "sort":"relevance"}
--David Frackelton, July 4
Was that on Wagn 0.9, David? I had this problem earlier too, and just now tried sll these characters - * : ` & ? - and got "Search returned no results". (We've switched to Wagn 0.10 here on wagn.org.)
If we don't actually search for (or interpret) such symbols, i'd prefer a message that lets users know we didn't actually search, rather than the current message, which makes it sound like we did a search but didn't find anything.
--John Abbe.....Sun Jul 06 16:43:02 -0700 2008
I noted build above 661
Browser says 0.10.0 on home page
Obtained by update from following repository.
svn update svn://rubyforge.org/var/svn/wagn/trunk wagn
Note search was put into search window not search for card window
< >
--David Frackelton.....Mon Jul 07 20:25:36 -0700 2008
Thanks - since i'm not coding i couldn't translate build to Wagn version #. Not sure what you mean by "search window" vs. "search for card window". Will alert Ethan & Lewis to this ticket...
--John Abbe.....Mon Jul 07 22:39:27 -0700 2008
Also, wondering about the angle brackets at the end of your comment - maybe you're running into stop filtering angle brackets when editing?
--John Abbe.....Mon Jul 07 22:47:46 -0700 2008
From the sql generated it looks to me like the issue David uncovered is not the funny characters per se but the handling of blank searches -- which is what we have after funny characters are stripped out. I would predict that the same funny characters would not break the search for David if they were included in a longer string, like "*logo".
Since we're not having this issue in installations that are using fulltext search, like all the ones running at wagn.org, my guess is that it has something to do with how simple (not fulltext enabled) searches are working elsewhere. We don't yet have fulltext working on mysql, so David's wagn must be one of these.
John, I think this ticket might be ready to close, and that we should open a new ticket for David's issue. Do you know of any problems that are clearly related to the characters issue?
--Ethan McCutchen.....Sun Jul 13 12:10:44 -0700 2008
Yes. I'd still like more accurate cue text. Ideally something that informs the user that we don't search for what they typed in, but i think a bare minimum would be to have the what follows "Card matching keyword:" reflect whatever stripping we do.
--John Abbe.....Mon Jul 14 01:51:59 -0700 2008
But the breakage is gone. So, closed this ticket, and opened improve cue text for stripped searches. David's issue is ticketed as catch blank searches when no fulltext search.
--John Abbe.....Tue Jul 22 20:54:21 -0700 2008
This has become more of a cues/documentation issue. See identify problem characters for search.
--John Abbe.....Sun Jan 04 03:03:36 -0800 2009