Dear Wiki user, You have subscribed to a wiki page or wiki category on "Solr Wiki" for change notification.
The following page has been changed by HossMan: http://wiki.apache.org/solr/TaskList The comment on the change is: rm items that are DONE or obsoleted by alternate improvements ------------------------------------------------------------------------------ This section is for ideas that are relatively straight forward or don't involve major changes to the Solr codebase. People who are eager to "give back" to the Solr community but don't have a lot of familiarity with the Solr code base may be interested in taking on these Tasks... - * Build a development tool that can run against the lucene jar (and contrib jars) and generate (stub) Factories for any Tokenizers or TokenFilters found that don't already exist in the solr code base ... this can be used anytime we update the version of lucene used, and the stubs could then be manually tweaked if the classes need additional options in their constructors. [https://issues.apache.org/jira/browse/SOLR-396 SOLR-396] * the bf param of dismax should be smarter then just splitting on whitespace (ie: don't split in the middle of parens) - * make delete support a list of Ids. .. perhaps let is support a mix of multiple ids or queries?, ie... {{{<delete><id>42</id><query>foo:bar</query><query>bax:yak</query><id>65</id><id>78</id></delete>}}} * "Build Instructions" should probably be moved out of README.txt and into a BUILD.txt and expanded on. - * Get someone smarter then hoss to review our jar/war MANIFEST file... - * is it as valid as it can be? - * should we include Class-Path info specifying the lib jars, or is it better to leave it out? * Create a ["Powered By Solr"] icon that people can include in their applications if they so choose. * all source code in "tgz" based releases should be processed by ant's `<fixcrlf>` in case someone prepares a release on a windows box + * alternate ways of indexing? + * over JMS - * alternate ways of indexing (it currently requires an HTTP POST of an XML document - * be able to load a text file, with variable delimiters (see also [http://issues.apache.org/jira/browse/SOLR-66 SOLR-66]) - * point it at a database and give it SQL [https://issues.apache.org/jira/browse/SOLR-469 SOLR-469] - * XML document over JMS * a !DateTime field (or Query Parser extension) that allows flexible input for easier human entered queries * allow alternate format for date output to ease client creation of date objects? - * [DONEish?] good multi-field querying support integrated with standard request handler, or as a separate handler - * see: DisMaxRequestHandler * support for max disjunction and minNrShouldMatch in query parser (really a Lucene item) * !UnitsFilter... 17" => 17 inch, etc * Admin query interface: add highlighting options, query writer options, facet options (see also [http://issues.apache.org/jira/browse/SOLR-67 SOLR-67]) * Documentation - * example schema.xml should showcase fields inheriting/overriding optiosn from fieldtypes, with comments explaining what's going on. SchemaXml should make it clear which "core" attributes of all !FieldTypes can be overridden by individual fields * Add to the existing tutorial, or write new tutorials discussing out of hte box features... * highlighting * dismax handler * the various output formats * simple facet counts + * DataImportHandler + * CSV Loading * result XML format - needed, or self-explanatory? * Java Docs * good overview.html @@ -67, +59 @@ * Support for IndexPartitioning within a single solr webapp instance * A more powerful query language allowing one to express complicated logic without resorting to a custom Java query handler plugin. * Make use of [http://jakarta.apache.org/hivemind/ HiveMind] or Spring for configuration & dependency injection - * [DONE] utilize Lucene's new field selector / lazy field loading mechanism to speed up requests that select only a few stored fields out of many. Beware interaction with the DocCache... it may need to be modified or bypassed. (see also [http://issues.apache.org/jira/browse/SOLR-52 SOLR-52]) - * [DONE] Implement flexible autoCommit/autoOptimize criteria (see [http://issues.apache.org/jira/browse/SOLR-65 SOLR-65] for some discussion) * Implement some ideas for ComplexFacetingBrainstorming * Implement some ideas to MakeSolrMoreSelfService - * [DONE via defaults and DateMath] support for an an optional "timestamp" style field in schemas which always want every doc to include the datetime the document was added to the index. This might be a special case (like the uniqueKey field) or it could involve more general "default" support for fields and fieldtypes (ie: `<field>` and `<fieldtype>` declarations could include a `default="..."` attribute that gets put into any document that doesn't already have a value for that field, with the underlying !FieldType parsing the text each time it's used, so that the !DateField class can convert `default="now"` to the current time. * support for composite keys ... either with some explicit change to the `<uniqueKey>` declaration or perhaps just copyField with some hidden magic that concats the resulting terms into a single key Term * investigate this "[http://mail-archives.apache.org/mod_mbox/lucene-java-user/200603.mbox/[EMAIL PROTECTED] SynonymQuery]" and how !SynonymFilter might be modified to set token types to trigger it's use automatically in !SolrQueryParser * FederatedSearch - * A "user query" parameter for standard request handler, much like what dismax handler has, for unstructured queries entered from a search box - * [DONEish?] ... the QParser abstraction and the components framework have basically make dismax and standard the same now * refactor and separate update XML parsing from update handling... possibly implement support for JSON updates. * [DONEish?] the refactoring is done, but still no JSON update support * [IN PROGRESS] refactor all of the JSP pages into request handler so a JDK/JSP compiler isn't needed (the current JSPs are very sparse on presentation, and use no custom tags, so there is almost no advantage to them being JSPs)
