Feature Proposal: Make METASEARCH Similar to SEARCH

Motivation

Currently, METASEARCH support search by only one criteria (be it the parent, topicinfo, form field,etc), and return the list of the topics found (separated by a whitespace).

This make this search nearly useless for formbased TWikiApplications, as the forms can only be queries against one field and the result can't be rendered in a nice way (i.e: A table) without resorting to some other plugin.

For an example, see the Bugs web in develop. It needs a "hack" using SEARCH to accomplish what should be done using METASEARCH.

Description

Make METASEACH similar to SEARCH, in the sense that it can query using multiple criteria and it's output can be formatted.

Alternatively, change the syntaxt of SEARCH to support metadata searching without hacks.

-- RafaelAlvarez - 13 Jul 2005

Impact and Available Solutions

Documentation

For each alternative, the documentation changes are shown.

(First Alternative: Modify METASEARCH)

• All options from SEARCH are also supported
• Example: %METASEARCH{type="field" "Type=(Bug|ChangeRequest);Status=Open" header="|*ItemNumber*|*Type*|*Status*|" format="| $field{ItemNumber} | $field{Type} | $field{Status}"}%

(Second Alternative: Modify SEARCH)

• Example: %SEARCH{"$formfield{Type}=(Bug|Feature);$formfield{Status}=(Closed)" scope="meta" web="Main" scope="topic"}%

Implementation

Any comments on how the feature is implemented or could be improved

Discussion:

I'd suggest that you look at FormQueryPlugin instead for a much more sophisticated (and much faster) method of searching metadata (and as a bonus any other kind of data).

-- ThomasWeigert - 13 Jul 2005

IMO the guts of the FQP should be brought into TWiki and METASEARCH should just be an interface to it.

-- MartinCleaver - 13 Jul 2005

Martin, I agree, in particular since with the recent changes I have made you can substitute it for both %SEARCH% and %METASEARCH%.

-- ThomasWeigert - 13 Jul 2005

FQP is one hell of a footprint to drag in!

The simple changes Rafael suggests - either one of the - would be more convenient.

In addition the point he makes about consistency is a good one.

-- AntonAylward - 13 Jul 2005

I'd far rather dump METASEARCH altogether. Meta-data fields are just fields, same as topic text and topic name. Why should the same search mechanism be used for all of them?

I do not favour dragging in FQP. I do favour replacing FQP with core mechanisms that make it redundant, such as SQL queries and flexible search result presentation.

-- CrawfordCurrie - 13 Jul 2005

Which is the same as dragging it in... I think Martin meant to have the functionality of FQP in core...

-- ThomasWeigert - 13 Jul 2005

Agreed on the combination of search and metasearch...

-- ThomasWeigert - 13 Jul 2005

I like the second alternative too (modifying SEARCH). But the METASEARCH variable should be retained for backward compatibility (two interfaces to the same engine) -- RafaelAlvarez - 14 Jul 2005

Now that someone mention it, has anybody tested DBD::SQLite?

-- RafaelAlvarez - 13 Jul 2005

What would be the timeline for SQL queries and flexible search result presentation?

-- ArthurClemens - 15 Feb 2006

This would be really useful and a far more efficient feature for what I need to achieve. For example, I am using the QuickMenuBar plugin and have complex searches to automatically create the javascript which in turn creates the menubar and the submenus. The submenu items are simply the children, but because SEARCH does not include meta and/or METASEARCH does not include format, I have to use the trick similar to the FAQ index which embeds a link to the parent from each child topic.

-- AlexSchuilenburg - 17 Aug 2006

Second option (modify SEARCH) was implemented in TWikiRelease04x00, albeit in a more powerful way. See QuerySearch

-- RafaelAlvarez - 13 Aug 2008