Hello all,
We have recently accelerated our timetable to moving to 2.0, and this sudden
immersion is what is causing our recent increase in bug reporting. Yesterday
morning I was exploring a problem with ISSN normalization, and I have spent the
last day trying to understand not only the
On Tue, Mar 8, 2011 at 11:24 AM, Dan Wells d...@calvin.edu wrote:
Hello all,
We have recently accelerated our timetable to moving to 2.0, and this sudden
immersion is what is causing our recent increase in bug reporting. Yesterday
morning I was exploring a problem with ISSN normalization,
--
*
Daniel Wells, Library Programmer Analyst d...@calvin.edu
Hekman Library at Calvin College
616.526.7133
On 3/8/2011 at 12:57 PM, Mike Rylander mrylan...@gmail.com wrote:
The drawbacks you mention in both of
On Tue, Mar 8, 2011 at 4:14 PM, Dan Wells d...@calvin.edu wrote:
On 3/8/2011 at 12:57 PM, Mike Rylander mrylan...@gmail.com wrote:
The drawbacks you mention in both of the above options you list are
among the reasons we don't do this currently. In particular, a
tsquery containing many ORed
I understand that the specific searches will work in any case, but it makes
me more than a little uncomfortable that adding normalizers to a specific
field will silently break searches at the class level. For instance, using
the default config, *any* identifier which contains a '-' but is
