Hello,
I'm customizing my XML response using with the XSLTResponseWriter using
"&wt=xslt&tr=transform.xsl". Because I have a few use-cases to support, I
wanted to break up the common bits and import/include them from multiple top
level xslt files, but it appears that the base directory of the tran
An interesting analogy for this feature is that you're doing a count(*) on a
group by in SQL. While it's true that you can pre-compute these if you have a
small set of combination you know you want to show a-priori, if you want to
present a more dynamic customer experience, you need to be able t
FWIW - I have no problem with the change.
Thanks,
Brian
- Original Message
From: Walter Underwood <[EMAIL PROTECTED]>
To: solr-user@lucene.apache.org
Sent: Friday, June 13, 2008 11:38:27 AM
Subject: Re: Seeking Feedback: non back compat for Java API of 3
FilterFactories in 1.3?
We us
t sounds like you are asking about the language/syntax for field
specification. Could/should you not use the ${fifi} syntax? We already use
that in solrconfig.xml, for example.
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
> From: Brian Johnson
Unfortunately that data set is long gone, but I can say that I am quite sure
the data was consistently sent to Solr with 3 digits of millis when I provided
the data in the documents. I confirmed this using luke and the data was
consistent, but the exception persisted. I looked into the associate
I am interested in using the suggest feature against a composition of other
more granular facets. Let me provide an example to help explain my problem and
proposed approaches.
Say I have a set of facets for these artifacts:
So far things work OK. Now I want my suggest feature to wor
: termfrequency
: 2008-04-24T09:03:53Z11076
: 2008-04-24T09:03:55Z10036
i'm assuming "11076" and "10036" are the term frequencies?
Yes - the cut-n-paste didn't do a good job separating the columns
: This now seems to be something different than SOLR-470 and SOLR-544
: since the format seems to
x, but is
still not accepted at query time.
Anyone have a suggestion?
Thanks,
Brian Johnson
----- Original Message
From: Brian Johnson <[EMAIL PROTECTED]>
To: solr-user@lucene.apache.org
Sent: Wednesday, April 23, 2008 11:23:54 AM
Subject: SOLR-470 & default value in schema
So I just ran into this bug:
https://issues.apache.org/jira/browse/SOLR-470
and read about this related one:
https://issues.apache.org/jira/browse/SOLR-544
Here is the relevant trace:
Apr 22, 2008 10:59:01 PM org.apache.solr.common.SolrException log
SEVERE: java.lang.RuntimeException: ja
The XML parser is probably not threadsafe but is being reused concurrently by
multiple post threads resulting in these exceptions. The observed 'randomness'
of the errors would be due to the unpredictable nature of the race condition
between threads. The reason you don't see this with smaller do
10 matches
Mail list logo
