Content-Type: multipart/alternative; boundary="_000_FAA7DF3F09441B4DA93A34DF745961404CA5976DVUEX14MB1vuadvi_" --_000_FAA7DF3F09441B4DA93A34DF745961404CA5976DVUEX14MB1vuadvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, that is exactly the problem. From: Joe Atzberger [mailto:joe@booksite.com] Sent: Tuesday, December 03, 2013 1:41 PM To: Demian Katz Cc: Michele Meloni; vufind-tech@lists.sourceforge.net Subject: Re: [VuFind-Tech] Facets natural sorting problem in browse catalog= ( case insensitive letters and numbers sort ) It has to be that the relationship of stored to indexed values is (potentia= lly) many to one. How would you display/identify a facet with one stored v= alue when there are 100 different stored values mapping into it? --joe On Tue, Dec 3, 2013 at 10:24 AM, Demian Katz > wrote: I'm not entirely sure why Solr made the decision to only use indexed values= for facets - it's possible it has to do with performance, or else it may b= e due to the issue that you have to use indexed values to match up identica= l facets correctly, and since different stored values can yield the same in= dexed value, there then becomes a problem with determining which value to d= isplay. In any case, one other possibility you might consider would be to u= se a delimited format - change your pipeline so that it would translate: my book 1 into: my book 000001|my book 1 and then have VuFind strip off the text before the | character. Again, not = a very pretty solution, but it would help you get away from doing natsort a= ll the time. - Demian I don't find the sense to display only indexed values! I think that we have too much records to use natsort every time but we can = try and see how are performances. Thanks! -- [LogoCineca] Michele Meloni Information and Knowledge Management Department Digital library Division Via R. Sanzio, 4 20090 Segrate MI, Italy tel. +39 02 26995 320 http://www.cineca.it ---------------------------------------------------------------------------= --- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics P= ro! http://pubads.g.doubleclick.net/gampad/clk?id=3D84349351&iu=3D/4140/ostg.cl= ktrk _______________________________________________ Vufind-tech mailing list Vufind-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/vufind-tech --_000_FAA7DF3F09441B4DA93A34DF745961404CA5976DVUEX14MB1vuadvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, that is exactly the = problem.

 <= /p>

From: Joe Atzb= erger [mailto:joe@booksite.com]
Sent: Tuesday, December 03, 2013 1:41 PM
To: Demian Katz
Cc: Michele Meloni; vufind-tech@lists.sourceforge.net
Subject: Re: [VuFind-Tech] Facets natural sorting problem in browse = catalog ( case insensitive letters and numbers sort )

 

It has to be that the relationship of stored to inde= xed values is (potentially) many to one.  How would you display/identi= fy a facet with one stored value when there are 100 different stored values= mapping into it?

 

--joe

 

On Tue, Dec 3, 2013 at 10:24 AM, Demian Katz <demian.katz@vil= lanova.edu> wrote:

I’m not entirely sure why Solr ma= de the decision to only use indexed values for facets – it’s po= ssible it has to do with performance, or else it may be due to the issue that you= have to use indexed values to match up identical facets correctly, and sin= ce different stored values can yield the same indexed value, there then bec= omes a problem with determining which value to display. In any case, one other possibility you might consi= der would be to use a delimited format – change your pipeline so that= it would translate:

 

my book 1

 

into:

 

my book 000001|my book 1

 

and then have VuFind strip off the text= before the | character. Again, not a very pretty solution, but it would help you get away from doing natsort all the time.

 

- Demian

 

I don't find the sense to display only indexed values!
I think that we have too much records to use natsort every time but we can = try and see how are performances.
Thanks!

--

3D"LogoCineca"<= /p>

Michele Meloni
Information and Knowledge Management Department
Digital library Division
Via R. Sanzio, 4
20090 Segrate MI, Italy
tel. +39 02 = 26995 320
http://www.cineca.it=

 


---------------------------------------------------------------------------= ---
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your<= br> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynami= cs Pro!
http://pubads.g.doubleclick.net/gam= pad/clk?id=3D84349351&iu=3D/4140/ostg.clktrk
_______________________________________________
Vufind-tech mailing list
Vufind-tech@lists.sour= ceforge.net
https://lists.sourceforge.net/lists/listinfo/vufind-tech

 

--_000_FAA7DF3F09441B4DA93A34DF745961404CA5976DVUEX14MB1vuadvi_--