EML file content out of sync with metacat
This is on dev.nceas.ucsb.edu. Search for soong_test. There should be 2 entries for "soong_test 1". One has ID soong_test.3.2 and the other has ID doc.1260314433875.1. Open doc.1260314433875.1 and look at the EML, which should be for soong_test.3.3.
I was testing the ecogrid writer actor in Kepler. I may not have been doing things correctly.
Updated by Matt Jones about 13 years ago
Please provide more information on what you were trying to do with the EcoGrid put actor, what precisely went wrong, and what you expected to happen. Its not clear from your description, and from your description it seems more likely that this is a Kepler bug than a Metacat bug. For example, why are there two versions of the metadata record -- is one an update of the other? Did you run the EcoGrid actor twice (how did both records get into Metacat)? How did you configure the EcoGrid actor to run with a template EML document -- it is supposed to take an EML document on input, so how did you generate it? Did the document that ended up in Metacat match the input you provided in Kepler? Etc.
If this is a bug in how the EcoGrid actor works then we should retarget it at Kepler so that its not in Mike's realm. Either way the issue needs significant clarification. Thanks.
Updated by Oliver Soong about 13 years ago
Yeah, I should have been clearer. I'm pretty sure I did something wrong with the actor in Kepler, but I wanted to raise all those sorts of questions like you're asking with somebody who knows how this thing is supposed to work. The point of the metacat bug is twofold.
1. There's something messy in the dev metacat database. I wanted to mention it just in case it caused other problems with the metacat.
2. If this condition does cause internal problems with metacat (I don't know, but it's outside "normal"), or if you all decide it should really never happen, then maybe there should be some validation before accepting it from Kepler.
I'm not certain yet that it's a Kepler bug so much as a PEBKAC.