Hi,
A month ago, the topic of a spell checker in Solr came up (c.f.
http://www.mail-archive.com/solr-user@lucene.apache.org/msg01254.html ).
Has anyone made any progress with that? If not, I'll have to do this to
scratch my own itch.
Because I'm in a hurry with this, I think I will go with the
couldn't you use a cdata section?
Chris Hostetter wrote:
Since XML is the transport for sending data to Solr, you need to make sure
all field values are XML escaped.
If you wanted to index a plain text "title" and that tile contained an
ampersand character
Sense & Sensability
...y
On 12/6/06, Graham O'Regan <[EMAIL PROTECTED]> wrote:
couldn't you use a cdata section?
That's just another form of escaping. Mirko actually want's the XML
field value to be part of the XML of Solr's response, not encapsulated
by it.
-Yonik
Many thanks to Hoss, Yonik, et al. for their excellent efforts to
bring faceted browsing to the masses! In most cases it works great!
But for some fields I have a need which is unfortunately not filled
by the current faceting code. These fields (Author Name, for
example) have too many discre
On 12/6/06, J.J. Larrea <[EMAIL PROTECTED]> wrote:
My thought was that the simplest approach would be to subclass
FieldCacheImpl to introduce a getMultiStringIndex method derived from
getStringIndex, defining and returning a MultiStringIndex class
which stores order as int[][] rather than int[];
What is necessary for the effects of changing the schema.xml to take
effect for all of my records? I restarted tomcat, but it does not seem
that my changes have taken effect.
I wanted to change a full-text field from type:string to type:text to
allow for better searching, but do no see any di
I think you have to reindex; new additions to your index will follow
the new schema but Solr doesn't reach in and reindex your old
information automatically.
Dave
On 12/6/06, Andrew Nagy <[EMAIL PROTECTED]> wrote:
What is necessary for the effects of changing the schema.xml to take
effect for a
: > which stores order as int[][] rather than int[]; a variant of
: > SimpleFacets.getFieldCacheCounts would simply need an inner loop to
: > tally each of the Document's Term indexes for that field.
:
: I think something like that is the right approach, the only problem
: being the size in memory
I reindexed and optimized and it helped. However now each query averages
about 1 second(down from 3-4 seconds). The bottleneck now is the
getFacetTermEnumCounts function. If I take that call out it is a non
measurable query time and the filtercache is being used. With the
getFacetTermEnumCounts
It is using the cache, but the number of items is larger than the size
of the cache.
If you want to continue to use the filter method then you need to
increase the size of the filter cache to something larger than the
number of unique values than what you are filtering on. I don't know
if you wi
It is currently a string type. Here is everything that has to do with manu
in my schema... Should it have been multi-valued? Do you see anything wrong
with this?
multiValued="true"/>
.
Thanks...
- Original Message -
From: "Yonik Seeley" <[EMAIL PROTECTED]>
To:
Sent: Wedn
Your snippet shows it as "text" not "string"
Try faceting on manu_exact and you may get better results.
-Yonil
On 12/6/06, Gmail Account <[EMAIL PROTECTED]> wrote:
It is currently a string type. Here is everything that has to do with manu
in my schema... Should it have been multi-valued? Do you
12 matches
Mail list logo
