Metacat

The 'casesensitive="true"' setting in Metacat pathquery expressions appears to be broken. All pathquery searches are handled as case-insensitive even when 'casesensitive="true"' is specified.

Here's the evidence:

(1) The following pathquery expression is executed in metacat. Note that
(a) casesensitive is set to "true"; and,
(b) the search term is entered as 'HoLoCEnE'.

<pathquery version="1.2">
<querytitle>Advanced Search</querytitle>
<returnfield>dataset/title</returnfield>
<returnfield>originator/individualName/surName</returnfield>
<returnfield>dataset/creator/individualName/surName</returnfield>
<returnfield>originator/organizationName</returnfield>
<returnfield>creator/organizationName</returnfield>
<returnfield>keyword</returnfield>
<querygroup operator="UNION">
<queryterm searchmode="contains" casesensitive="true">
<value>HoLoCEnE</value>
<pathexpr>dataset/title</pathexpr>
</queryterm>
<queryterm searchmode="contains" casesensitive="true">
<value>HoLoCEnE</value>
<pathexpr>dataset/abstract/para</pathexpr>
</queryterm>
<queryterm searchmode="contains" casesensitive="true">
<value>HoLoCEnE</value>
<pathexpr>dataset/abstract/section/para</pathexpr>
</queryterm>
<queryterm searchmode="contains" casesensitive="true">
<value>HoLoCEnE</value>
<pathexpr>keyword</pathexpr>
</queryterm>
</querygroup>
</pathquery>

(2) The Tomcat log outputs the SQL statements as follows. Note that the search term being matched in the database is specified as '%HOLOCENE%'. This would indicate that the casesensitive="true" specified in the pathquery expression is being ignored or lost at some point between step 1 and step 2:

2008-08-19 13:48:57.200 Metacat: [WARN] [edu.ucsb.nceas.metacat.QuerySpecification]: accessquery is: AND (docid IN (SELECT docid from xml_access WHERE = 'public') AND perm_type = 'allow' AND permission > 3)) AND docid NOT IN (SELECT docid from xml_access WHERE = 'public') AND perm_type = 'deny' AND perm_order ='allowFirst' AND permission > 3) ))
2008-08-19 13:48:57.200 Metacat: [WARN] [edu.ucsb.nceas.metacat.DBQuery]: ============ final selection query: SELECT docid,docname,doctype,date_created, date_updated, rev FROM xml_documents WHERE docid IN ((SELECT DISTINCT docid FROM xml_path_index WHERE (UPPER LIKE '%HOLOCENE%' AND path IN ('dataset/title','dataset/abstract/para','dataset/abstract/section/para','keyword')))) AND (docid IN (SELECT docid from xml_access WHERE = 'public') AND perm_type = 'allow' AND permission > 3)) AND docid NOT IN (SELECT docid from xml_access WHERE = 'public') AND perm_type = 'deny' AND perm_order ='allowFirst' AND permission > 3) ))
2

(3) The search matches documents containing the keyword 'holocene'.

To reproduce this test in the LTER Data Catalog:

1. Browse to http://metacat.lternet.edu
2. Select the 'Advanced Search' link.
3. Enter 'HoLoCEnE' in the subject field.
4. Select the 'Case sensitive' checkbox in the 'Search Options' section
5. Click the 'Search' button.

The output shown above was taken from the LTER Metacat Tomcat log file (catalina.out). This seems like pretty solid evidence that the bug is in Metacat itself and not in the Advanced Search form or the LTER skin, because the pathquery expression is being processed incorrectly by Metacat when it composes its SQL statement.