Hi Tom, Thanks. This has to do with namespacing and the need to support legacy users of the software wherein which CAS.ProductId was the standard field used. To support this, in the CoreMetExtractor FM met extractor, we allow namespacing (e.g., "CAS." to be used on the core met keys).
However, newer users of the system have a path for not having to use CAS. if needed. It's not recommended though since I am not sure of the full widespread use (e.g., in downstream UIs, etc.) of CAS as a prefix. That being said, I think CoreMetKeys.PRODUCT_ID is *still* correct, as "ProductId", however, in this case, I put (on my comment on r/4709/ that we should do: "CAS." + CoreMetKeys.PRODUCT_ID. Sound good? +1 for that. Cheers, Chris On Apr 13, 2012, at 5:07 AM, Thomas Bennett wrote: > Hey Paul and Chris, > > I'm just following up with an email - see my comment in > https://reviews.apache.org/r/4709/. > > It seems that CoreMetKeys.PRODUCT_ID = "ProductId" and not "CAS.ProductId" as > specified in the cas-filemgr/policy/elements.xml file. > > Should they be the same? > > Cheers, > Tom > > On 12 April 2012 12:32, Ramirez, Paul M (388J) <[email protected]> > wrote: > This UUID stuff should have been dropped when it was ported to Apache. This > was a project specific thing where the team that developed it had a different > unique id (UUID). > > --Paul > > On Apr 11, 2012, at 6:06 PM, "Thomas Bennett" <[email protected]> wrote: > >> Hey Chris, >> >> Here's a basic summary of what I've discovered so far getting my metadata >> into a Solr index... >> >> SolrIndexer queries metadata for a single or multiple products from a File >> Manager and put them into a Solr index. It does this by an http POST to >> solr/update. Very cool. >> >> Because it's xml on the wire, its really easy to tcpdump and view the actual >> POST and see what the content is :). This is how I discovered that the >> indexAll was not updating solr (see below). >> >> Okay so for a simple test, I set up the following mapping, since these >> fields already exist in the Solr schema.xml file: >> >> map.ExperimentID=id >> map.Observer=author >> map.Description=description >> >> Note: It seems a good idea to have an "id" field. If you look in the solr >> scheme.xml file, I saw the following configuration by default: >> >> <!-- Field to use to determine and enforce document uniqueness. >> Unless this field is marked with required="false", it will be a >> required field >> --> >> <uniqueKey>id</uniqueKey> >> >> Okay, so I finally ran the SolrIndexer with the -all. >> >> This piece of code (starting at line 209 of SolrIndexer.java) was never >> executed. It's checking for metadata "UUID". I don't have this metadata key. >> >> if (metadata.getMetadata("UUID") != null) { >> if (metadata.getMetadata("Deleted") == null >> >> || !"true".equals(metadata.getMetadata("Deleted"))) { >> >> try { >> >> server.add(this.getSolrDocument(metadata)); >> >> server.commit(); >> >> LOG.info("Indexed " + metadata.getMetadata("UUID")); >> >> } catch (Exception e) { >> >> LOG.severe("Could not index " + >> metadata.getMetadata("UUID") >> >> + " " + e.getMessage()); >> >> } >> >> } else { >> >> LOG.info("Skipping Deleted: " + >> metadata.getMetadata("UUID")); >> >> } >> >> } >> >> Question: Deleted looks optional, so no problem there, but what should I be >> doing with UUID? I've changed this to be CAS.ProductId in the code, just to >> check nothing else was causing a problem. I thought it would be worth >> asking why UUID is specified... >> >> I've tried the single product index, which works just fine. >> >> Cheers, >> Tom >> >> On 30 March 2012 20:38, Mattmann, Chris A (388J) >> <[email protected]> wrote: >> No worries...based on your email below, did you update the Solr schema? I >> think you need >> to tell it to allow for all fields, by uncommenting the dynamicField block >> in the schema.xml file >> to say "allow all fields" to come through, or modify the schema.xml in >> Solr's conf directory to >> specify which fields to send to Solr. >> >> Does that make sense? I can provide more detailed help and will follow up >> later, but >> see if that helps for now. >> >> Cheers, >> Chris > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: [email protected] WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
