Bug #5395
closedGet unexpected result if a search was done before metacat finishes its indexing during the inserting process.
0%
Description
Hi, Scott:
I dug around this issue a while and found it out it was a search cache issue in Metacat. Did you do an immediate search after you uploaded the szalt4twittergraph?
I guess you did a search before Metadata finished its indexing during the inserting (uploading), so the search didn't get the name of kar xml and docid of kar file. The worse case is that the broken search result was cached and it will persist forever. The only way to resolve the problem is to remove the cached item.
After I deleted the record of this document in the xml_queryresult table (the search cache table), the search worked for me. You might make a try as well. If you see any problem, please let me know.
I will file a bug about this issue.
Thanks,
Jing
Scott Zimmer wrote:
I am trying to upload some kar files that I created to the Kepler-Dev repository. I upload them from inside Kepler-2.2 and I always get the message that the component uploaded successfully. I am making them publicly available and logging in anonymously. Sometimes when I search the repository through the website (http://kepler-dev.nceas.ucsb.edu/kepler/metacat) I get "null" as the kar name and if I click download, I get the following return
<error>the requested docid '' does not exist</error>I can still find the uploaded component if I search the repository from inside Kepler and I can drag it onto my canvas. I have uploaded szalt3twittergraph and szalt4twittergraph to the repository. I can find both kar files from within Kepler, but szalt4twittergraph shows up as null and can't be downloaded from the repository via the website. I'd appreciate any insight you have into the cause.
Scott
Related issues
Updated by ben leinfelder over 11 years ago
- Assignee changed from Chad Berkley to Jing Tao
- Target version changed from Unspecified to 2.1.0
There's nothing we can do about the indexing delay unless we perform indexing while blocking the insert/upload process. I don't think we want to go in that direction and our design for using SOLR is completely asynchronous. The good thing about the SOLR implementation is that the query result cache will not prevent the record from showing up once it has actually been indexed by SOLR.
Updated by ben leinfelder over 11 years ago
- Target version changed from 2.1.0 to 2.x.y
Deferring - though we don't really have a solution for this. Only affects a deprecated mechanism (pathquery), however.
Updated by ben leinfelder over 11 years ago
- Status changed from New to Rejected
I think we should mark this as 'won't fix' since it is part of the deprecated pathquery feature.