On 3 December 2012 19:51, helix84 <[email protected]> wrote: > On Mon, Dec 3, 2012 at 7:20 AM, Ian Boston <[email protected]> wrote: >> 2012-12-03 06:11:36,618 ERROR org.dspace.browse.SolrBrowseCreateDAO @ >> Null metadata value for item 1542, field: dc.contributor.advisor > > This does look strange, assuming you really have a text_value for that > row there. > > Both updating index and reindexing worked fine on my DSpace 3.0 > instance upgraded from 1.8. > > I'm wondering about that SolrBrowseCreateDAO part, not sure if it's > supposed to be there, or if it's supposed to use the Postgres/Oracle > DAO. This is new in DSpace 3.0: > https://github.com/DSpace/DSpace/blob/dspace-3.0/dspace/config/dspace.cfg#L872 > > > Maybe if you could change this part to log what document it's trying > to write, we'd see what's wrong: > https://github.com/DSpace/DSpace/blob/dspace-3.0/dspace-api/src/main/java/org/dspace/discovery/SolrServiceImpl.java#L601 > > > Another thing I'd look at is changes in the value of the multiValued > attribute in the Solr search schema, see if that gives you a clue: > git diff --ignore-space-at-eol dspace-1_8_x dspace-3.0 > dspace/solr/search/conf/schema.xml > But I can't explain why any such error would occur when rebuilding the > index from scratch.
I am not massively experienced with DSpace, but have a reasonable amount of exposure to Solr (especially Solr4). The error normally happens when a SolrJ client tried to put multiple values into a fields that was declared with no multiValued attribute or multiValued=false. Normally the error message tells you exactly which one it is, but the log messages on the Solr sever side dont look very normal. I am going to guess the fields is being defined by one of the field templates... but which one? In the offending line that causes the exception (not the one reporting null), there is a reference to a handle that contains several fields that are multi values. Perhaps the solr schema is not expecting subject to be multi valued ? I dont think this is a problem with a normal DSpace data set. Its more likely to be a problem with the DSpace@Cambridge dataset which has been living in a modified DSpace that forked 5 or 6 years ago probably at 1.4 or maybe 1.5. There are a lot of items, and hence a lot of opportunity for all sorts of weird metadata. I was impressed that the data migration to an unpatched DS3 worked. I'll hack the code a bit to see what exactly the problematic field is. Ian > > > Regards, > ~~helix84 > > Compulsory reading: DSpace Mailing List Etiquette > https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette ------------------------------------------------------------------------------ Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
