Hi,
excellent, good to hear that you got this resolved! Also, thanks for
keeping the list in the loop -- this might help in case anyone else runs
into the same problem sometime in the future. So it looks like the
initial issue was that you had dc.type listed as a hidden metadata
field; then when
Issue resolved, finally! =)
update-discovery-index -f ran just fine and indexed everything.
Now all items have the type field and can be filtered correctly.
Don't know what happened to update-discovery-index -b to fail, but -f is
enough to update the index for a new filter.
Maybe an update to
As it looks as not asked before...
have you reindex your content after have changed the discovery
configuration?
as you have noted the filter are index under a different SOLR field, in
your case type
bean id=searchFilterType
class=org.dspace.discovery.configuration.DiscoverySearchFilter
On Wed, Aug 7, 2013 at 8:36 AM, Andrea Bollini a.boll...@cineca.it wrote:
The metadata are automatically indexed in discovery in the form
schema.element.qualifier so it is right that you already have dc.type in
your index but if have added the type searchFilter only recently it only
affect
yes, this was my guess
Il 07/08/2013 08:56, helix84 ha scritto:
On Wed, Aug 7, 2013 at 8:36 AM, Andrea Bollini a.boll...@cineca.it wrote:
The metadata are automatically indexed in discovery in the form
schema.element.qualifier so it is right that you already have dc.type in
your index but if
Hello everyone,
First of all thanks for helping me out.
I did an update-discovery-index -b when I created the new filter, this
should work as well as -f, correct?
Last night I scheduled a new update-discovery-index -b.
I think the problem is that it did not run completely. It ran for only
about 4
Hi,
On 08/08/13 06:46, Alcides Carlos de Moraes Neto wrote:
I think the problem is that it did not run completely. It ran for only
about 4 minutes. I noticed the items it did log as written do work
with the filter.
...and at least one of them has a repeated dc.type, so that's not the
problem
I checked the catalina.out for errors but could not find anything.
I trimmed it, beginning at 22:00 and uploaded it.
(SOLR log is really verbose, too big for pastebin)
https://dl.dropboxusercontent.com/u/4193365/catalina.out.22h
I'll try an update-discovery-index -f tomorrow...
Ats,
Alcides
Hi,
On 08/08/13 11:55, Alcides Carlos de Moraes Neto wrote:
I checked the catalina.out for errors but could not find anything.
No, nothing looks suspicious. Very strange.
I'll try an update-discovery-index -f tomorrow...
Good luck and let us know what happens. It might be interesting to see
No, it's actually the value I expect, 260078
SOLRResponse:
response
lst name=responseHeader
int name=status0/int
int name=QTime52/int
lst name=params
str name=indenttrue/str
str name=rows0/str
str name=qdc.type:text/str
/lst
/lst
result name=response numFound=260078 start=0/
/response
DSpace
Looking at the solr logs, i see that the discovery filter is passed to SOLR
as a parameter fq=type
http://www22.senado.leg.br/solr/search/select?indent=truerows=0q=dc.type:[*+TO+*]fq=type:(text)
This will only return:
result name=response numFound=2189 start=0/
How does filter queries work in
Hi,
On 07/08/13 08:45, Alcides Carlos de Moraes Neto wrote:
Looking at the solr logs, i see that the discovery filter is passed to
SOLR as a parameter fq=type
http://www22.senado.leg.br/solr/search/select?indent=truerows=0q=dc.type:[*+TO+*]fq=type:(text)
Thank you for your response Andrea,
Did you by any chance add dc.type to the list of hidden metadata fields?
https://github.com/DSpace/DSpace/blob/dspace-3.1/dspace/config/dspace.cfg#L737
metadata.hide.dc.type = false
It was indeed set to TRUE. I changed it to FALSE, restarted tomcat, and
About metadata for item types, see latest IRUS report:
http://wiki.lib.sun.ac.za/images/c/c6/Irus-item-type-report-Jan2013-v2-0.pdf
On 5 August 2013 20:14, Alcides Carlos de Moraes Neto
alcides.n...@gmail.com wrote:
Thank you for your response Andrea,
Did you by any chance add dc.type to
Thank you Hilton, i'll pass this to the librarians responsible. I'm just
the 'computer guy'. =)
Andrea,
It seems removing the line from dspace.cfg resolved the issue. Now both
items show dc.type.
(This is a bug right? because my line was setting it to FALSE).
I'll see now if discovery manages to
Hi,
On 06/08/13 07:13, Alcides Carlos de Moraes Neto wrote:
It seems removing the line from dspace.cfg resolved the issue. Now
both items show dc.type.
(This is a bug right? because my line was setting it to FALSE).
I think we can argue about this being a bug or not :) The dspace.cfg
comments
2013/8/5 Andrea Schweer schw...@waikato.ac.nz
If you have command line access to your server, could you try querying
solr directly to check how many items have dc.type indexed at all? This
might help determine whether the problem is in the user interface or
somewhere deeper. Something like
Hi,
On 06/08/13 10:09, Alcides Carlos de
Moraes Neto wrote:
It seems SOLR has indexed dc.type
correctly:
response
lstname="responseHeader"
Hi there,
On 03/08/13 07:47, Alcides Carlos de Moraes Neto wrote:
I have this situation in my workplace's dspace installation. Most (if
not all) of the items have the dc.type metadata set, but it is only
appearing in a few instances. Check out these examples:
Shows dc.type:
I have this situation in my workplace's dspace installation. Most (if not
all) of the items have the dc.type metadata set, but it is only appearing
in a few instances. Check out these examples:
Shows dc.type: http://www2.senado.leg.br/bdsf/handle/id/190819?show=full
Does not show dc.type:
20 matches
Mail list logo
