[
https://issues.apache.org/jira/browse/SOLR-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tricia Williams updated SOLR-380:
-
Attachment: SOLR-380-XmlPayload.patch
Functionality is improved. Tests are more complete. I have
[
https://issues.apache.org/jira/browse/SOLR-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Klaas updated SOLR-112:
Fix Version/s: (was: 1.3)
> Hierarchical Handler Config
> ---
>
>
On 14-Nov-07, at 12:00 AM, Paul Elschot wrote:
On Wednesday 14 November 2007 06:42:56 Mike Klaas wrote:
...
... I was
imagining that it was necessary to embed the filter clauses in the
"core" to produce an effective implementation. By the time I
finished my response, I had read enough of the
A small FYI: I noticed that I accidently commited a change several
months ago that reordered doc ids before retrieval. It is now fixed.
I doubt that it would really affect anyone, but it did add a few
allocations, so for doc-retrieval-heavy applications using trunk, you
may want to sync.
Forget my previous message; the experimentation proved to require more
modifications than anticipated and a lot of added complexity.
The only thing that came out of it is that I (finally) understood your idea
of using ThreadLocal to implement a workaround in case the APIs can not
move.
--
View t
Instead of changing 'init' (& keeping the 1.2 version), we can either make
classes take a solrSystem as (first) constructor parameter (but I know this
is not the current nor preferred usage)
Are you saying 'if a constructor exists that takes a solrSystem, it will
use that - otherwise, just th
I may have an alternative that would preserve the existing 1.2 'init' APIs
and still keep (hopefully all) the solr-399 features.
To instantiate a core, we need a schema and config; to instantiate a schema,
we need a config - and the core config & schema config should be the same.
I'm experimenti
