NCEAS / metacat

Data repository software that helps researchers preserve, share, and discover data
https://knb.ecoinformatics.org/software/metacat
GNU General Public License v2.0
25 stars 12 forks source link

Advanced Search needs some attention #476

Closed mbjones closed 6 years ago

mbjones commented 6 years ago

Author Name: Callie Bowdish (Callie Bowdish) Original Redmine Issue: 3177, https://projects.ecoinformatics.org/ecoinfo/issues/3177 Original Date: 2008-03-17 Original Assignee: Jing Tao


Currently the KNB has a link to the advanced search. The advanced search is too slow and does not have very many advanced search options. I do not think it is working with the improvements that have been made for query caching.

http://knb.ecoinformatics.org//advancedsearch.jsp

the LTER skins advanced search on the KNB metacat has more options but the search is very slow http://knb.ecoinformatics.org/knb/style/skins/lter/index_advancedsearch.jsp

However the advanced search on the LTER metacat (not knb) appears to be working fine. Maybe their solution will help with updating our advanced search. I'm not sure why the http://metacat.lternet.edu advanced search is working well and the http://knb.ecoinformatics.org metacat is so slow.

http://metacat.lternet.edu/knb/style/skins/lter/index_advancedsearch.jsp

mbjones commented 6 years ago

Original Redmine Comment Author Name: Duane Costa (Duane Costa) Original Date: 2008-03-18T00:32:16Z


Jing, I think I have an explanation for why advanced search in the LTER skin would be faster at metacat.lternet.edu than at knb.ecoinformatics.org. The key is the indexPaths property in the build.properties file. I have fine-tuned the indexPaths setting at LTER such that all EML fields searched by the advanced search code are included in the indexPaths list. When this is not the case, the advanced search does perform extremely slow (as you are seeing at knb).

Below is the setting that we are using at LTER. If you cross-reference the values used in metacat.lternet.edu with those at knb.ecoinformatics.org, you will probably find a number of fields that were added to the LTER setting (and perhaps some fields that are used in KNB but not at LTER).

indexPaths=@packageId,@system,abstract/para,abstract/section/para,alternativeTimeScale/timeScaleName,associatedParty/individualName/givenName,associatedParty/individualName/surName,associatedParty/organizationName,creator/individualName/givenName,creator/individualName/surName,creator/organizationName,dataset/abstract/para,dataset/abstract/section/para,dataset/access/allow/principal,dataset/creator/individualName/givenName,dataset/creator/individualName/surName,dataset/dataTable/physical/distribution/online/url,dataset/spatialRaster/physical/distribution/online/url,dataset/title,eastbc,eastBoundingCoordinate,EcogridRegEntry/description,EcogridRegEntry/endPoint,EcogridRegEntry/serviceName,entityName,geographicCoverage/boundingCoordinates/eastBoundingCoordinate,geographicCoverage/boundingCoordinates/northBoundingCoordinate,geographicCoverage/boundingCoordinates/southBoundingCoordinate,geographicCoverage/boundingCoordinates/westBoundingCoordinate,geographicDescription,givenName,keyword,northbc,organizationName,originator/individualName/givenName,originator/individualName/surName,originator/organizationName,southbc,surName,taxonRankValue,westbc

mbjones commented 6 years ago

Original Redmine Comment Author Name: Redmine Admin (Redmine Admin) Original Date: 2013-03-27T21:22:31Z


Original Bugzilla ID was 3177

mbjones commented 6 years ago

Original Redmine Comment Author Name: ben leinfelder (ben leinfelder) Original Date: 2013-04-10T16:18:36Z


We basically know that searching on non-indexed paths takes a very long time. This will ultimately be replaced by the SOLR-implementation and we will just have to conscious of index paths being correct for any pathquery that is submitted via default skins in the interim.