Advanced search on identifer: Omeka hangs

I am in the process of simplifying the search process on our website:

I have replaced the simple search in the side bar with a link to a stripped down advanced search. The keyword search is removed to reduce the bulk of records that might return. Only the advanced search is available, with blacklisted fields.

I have noticed that Omeka will hang, once an identifier has been added to the search. Consequent searches are not possible until Firefox is restarted. Initially I thought the blacklisted items caused this, but even when those were removed, the hang kept occurring.

The search on 'identifier' is quite essential for our collection, as the object are often referred to by the identifier in artciles etc. Even if more than four consequtive characters are filled in, Omeka hangs. Our identifiers consist of a combination of letters, numbers and dots, i.e. ARM ADM 1.22.10

Is there any way I can fix this problem? The search page is accessible on http://arpc65.arm.ac.uk/omeka/items/advanced-search

Currently the advanced_search.php looks as follows:

<?php
if (!$isPartial): // If we are using the partial view of this search form.

head(array('title'=>'Advanced Search', 'bodyclass' => 'advanced-search', 'bodyid' => 'advanced-search-page'));
?>

<h1>Search Collections</h1>

<div id="primary">
<?php endif; ?>
<?php if (!$formActionUri): ?>
    <?php $formActionUri = uri(array('controller'=>'items', 'action'=>'browse')); ?>
    <?php echo js('jquery'); ?>
<script type="text/javascript" charset="utf-8">
  jQuery.noConflict();
  jQuery(document).ready(function() {
      var blackListElements = new Array();
      blackListElements[0] = "Coverage";
      blackListElements[1] = "Creator";
      blackListElements[2] = "Language";
       blackListElements[3] = "Rights";
        blackListElements[4] = "Source";
         blackListElements[5] = "Subject";
          blackListElements[6] = "Type";
           blackListElements[7] = "1st Author Initials";
            blackListElements[8] = "1st Author Surname";
             blackListElements[9] = "2nd Author Initials";
            blackListElements[10] = "2nd Author Surname";
                blackListElements[11] = "3rd Author Initials";
            blackListElements[12] = "3rd Author Surname";
                blackListElements[13] = "Atlas Cat";
            blackListElements[14] = "Author Ref";
             blackListElements[15] = "BCC";
                blackListElements[16] = "Bibliography";
            blackListElements[17] = "Biographical Text";
            blackListElements[18] = "Birth Date";
                blackListElements[19] = "Birthplace";
            blackListElements[20] = "Bit Rate/Frequency";
              blackListElements[21] = "CC";
            blackListElements[22] = "Compression";
                blackListElements[23] = "Date Published";
            blackListElements[24] = "Date Received";
             blackListElements[25] = "Death Date";
                blackListElements[26] = "Director";
            blackListElements[27] = "Duration";
            blackListElements[28] = "Edition";
                blackListElements[29] = "Email Body";
            blackListElements[30] = "Event Type";
               blackListElements[31] = "Flag";
            blackListElements[32] = "Interviewee";
                blackListElements[33] = "Interviewer";
            blackListElements[34] = "From";
             blackListElements[35] = "ISBN";
                blackListElements[36] = "Lesson Plan Text";
            blackListElements[37] = "Local URL";
            blackListElements[38] = "Location";
                blackListElements[39] = "Maker";
            blackListElements[40] = "Materials";
               blackListElements[41] = "Misc Info";
            blackListElements[42] = "Name";
                blackListElements[43] = "Number of Attachments";
            blackListElements[44] = "Number of parts";
             blackListElements[45] = "Objectives";
                blackListElements[46] = "Occupation";
            blackListElements[47] = "Original Format";
            blackListElements[48] = "Participants";
                blackListElements[49] = "Physical Dimensions";
            blackListElements[50] = "Producer";
               blackListElements[51] = "Published";
            blackListElements[52] = "Standards";
                blackListElements[53] = "Storage id";
            blackListElements[54] = "Subject Line";
             blackListElements[55] = "Subject Ref";
                blackListElements[56] = "Text";
            blackListElements[57] = "Time Summary";
            blackListElements[58] = "";
                blackListElements[59] = "To";
            blackListElements[60] = "Transcription";
             blackListElements[61] = "UBSC";
                blackListElements[62] = "UDCS";
            blackListElements[63] = "URL";
      for (var i = 0; i < blackListElements.length; i++){
           jQuery("#advanced-0-element_id option[label='" +
blackListElements[i] + "']").hide();
      }
  });
</script>
<?php endif; ?>

<form <?php echo _tag_attributes($formAttributes); ?> action="<?php echo html_escape($formActionUri); ?>" method="get">

	<div id="search-narrow-by-fields" class="field">

		<div class="label">Narrow by Specific Fields</div>

			<div class="inputs">
				<?php
				//If the form has been submitted, retain the number of search fields used and rebuild the form
				if(!empty($_GET['advanced'])) {
					$search = $_GET['advanced'];
				}else {
					$search = array(array('field'=>'','type'=>'','value'=>''));
				}

				//Here is where we actually build the search form
				foreach ($search as $i => $rows): ?>
					<div class="search-entry">	

					<?php
					//The POST looks like =>
					// advanced[0] =>
						//[field] = 'description'
						//[type] = 'contains'
						//[terms] = 'foobar'
					//etc
					echo select_element(
						array('name'=>"advanced[$i][element_id]"),
						@$rows['element_id'],
						null,
						array('record_types'=>array('Item', 'All'), 'sort'=>'alpha')); ?>

					<?php
						echo select(
							array('name'=>"advanced[$i][type]"),
							array('contains'=>'contains', 'does not contain'=>'does not contain', 'is empty'=>'is empty', 'is not empty'=>'is not empty'),
							@$rows['type']
						);
					?>

					<?php
						echo text(
							array('name'=>"advanced[$i][terms]", 'size'=>20),
							@$rows['terms']);
					?>
					<button type="button" class="remove_search" disabled="disabled" style="display: none;">-</button>
					</div>
				<?php endforeach; ?>
			</div>
			<button type="button" class="add_search">Add a Field</button>
		</div>

	<?php is_admin_theme() ? fire_plugin_hook('admin_append_to_advanced_search') : fire_plugin_hook('public_append_to_advanced_search'); ?>
	<div>
	    <input type="submit" class="submit submit-medium" name="submit_search" id="submit_search_advanced" value="Search" />
    </div>
</form>

<?php echo js('search'); ?>
<script type="text/javascript">
    jQuery(document).ready(function () {
        Omeka.Search.activateSearchButtons();
    });
</script>
<?php if (!$isPartial): ?>
    </div> <!-- Close 'primary' div. -->
    <?php foot(); ?>
<?php endif; ?>

It looks like your server is taking a really long time to respond to searches that specify the Identifier.

The first things I'd try would be running "REPAIR TABLE" and "OPTIMIZE TABLE" on all your Omeka tables. You can do both of these easily from phpMyAdmin.

Thanks for your reply, John. I had read similar advice in other posts, but I have had no way to access through phpMyAdmin, yet. I have asked the systems manager to look into it for me. I'll get back when I have news either way!

Brilliant! Together with the systems manager I found my way, took your advice, and now the searches work like a charm.

Thank you and the team so much for your help over the last few weeks!

Glad to hear this worked for you. I can certainly confirm that the search is running much faster than before.

In particular the OPTIMIZE TABLE command can sometimes greatly improve search performance. In your site's case, the search went from taking tens of minutes to a few seconds.

I remembered recently seeing this post about advanced searching, but I had some trouble locating it. I used the "Search Omeka.org" search box at the top of the page to search for the words "advanced search." However, this post did not appear amongst the 13 results. I eventually found it again by clicking on subtopics in the forums, first Troubleshooting and a few others before I finally found it in the Themes and Public Display group.

Would it be possible to have the Recent Discussions allow you to go further back by having a previous button to see earlier posts? Also is there a reason why this post didn't appear in the search I ran?

Does this need to be done fairly often? I'm wondering if there's some sort of CRON job that can be set up to make sure this issue doesn't creep back into the site.

You normally shouldn't need to do this, or at least shouldn't need to do it often, but lots of churn in your data can fragment your table on disk and lead to this problem (as well as some wasted space).

You certainly could set up a cronjob to periodically optimize (among other things) your tables.

Running the command:

mysqlcheck -u <db_username> -p -ao –auto-repair <db_name>

(where the parts in angle brackets are replaced with your corresponding database credentials) will REPAIR, ANALYZE, and OPTIMIZE all the tables in your Omeka database.