[jira] Updated: (SOLR-731) CoreDescriptor.getCoreContainer should not be public
[ https://issues.apache.org/jira/browse/SOLR-731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated SOLR-731: --- Fix Version/s: 1.3.1 > CoreDescriptor.getCoreContainer should not be public > > > Key: SOLR-731 > URL: https://issues.apache.org/jira/browse/SOLR-731 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Henri Biestro > Fix For: 1.3.1 > > Attachments: solr-731.patch > > > For the very same reasons that CoreDescriptor.getCoreProperties did not need > to be public (aka SOLR-724) > It also means the CoreDescriptor ctor should not need a CoreContainer > The CoreDescriptor is only meant to be describing a "to-be created SolrCore". > However, we need access to the CoreContainer from the SolrCore now that we > are guaranteed the CoreContainer always exists. > This is also a natural consequence of SOLR-647 now that the CoreContainer is > not a map of CoreDescriptor but a map of SolrCore. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-735) CoreContainer.unload should remove all aliases of a core
[ https://issues.apache.org/jira/browse/SOLR-735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated SOLR-735: --- Fix Version/s: 1.3.1 > CoreContainer.unload should remove all aliases of a core > > > Key: SOLR-735 > URL: https://issues.apache.org/jira/browse/SOLR-735 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Henri Biestro > Fix For: 1.3.1 > > > Similar to SOLR-722, this is a *core* operation (like load/reload); it should > affect all aliases of a core. > In this case, it should close the core through all its aliases. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[ https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated SOLR-725: --- Fix Version/s: 1.3.1 > CoreContainer/CoreDescriptor/SolrCore cleansing > --- > > Key: SOLR-725 > URL: https://issues.apache.org/jira/browse/SOLR-725 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Henri Biestro > Fix For: 1.3.1 > > Attachments: solr-725.patch, solr-725.patch, solr-725.patch > > > These 3 classes and the name vs alias handling are somewhat confusing. > The recent SOLR-647 & SOLR-716 have created a bit of a flux. > This issue attemps to clarify the model and the list of operations. > h3. CoreDescriptor: describes the parameters of a SolrCore > h4. Definitions > * has one name > ** The CoreDescriptor name may represent multiple aliases; in that > case, first alias is the SolrCore name > * has one instance directory location > * has one config & schema name > h4. Operations > The class is only a parameter passing facility > h3. SolrCore: manages a Lucene index > h4. Definitions > * has one unique *name* (in the CoreContainer) > **the *name* is used in JMX to identify the core > * has one current set of *aliases* > **the name is the first alias > h4. Name & alias operations > * *get name/aliases*: obvious > * *alias*: adds an alias to this SolrCore > * *unalias*: removes an alias from this SolrCore > * *name*: sets the SolrCore name > **potentially impacts JMX registration > * *rename*: picks a new name from the SolrCore aliases > **triggered when alias name is already in use > h3. CoreContainer: manages all relations between cores & descriptors > h4. Definitions > * has a set of aliases (each of them pointing to one core) > **ensure alias uniqueness. > h4. SolrCore instance operations > * *load*: makes a SolrCore available for requests > **creates a SolrCore > **registers all SolrCore aliases in the aliases set > **(load = create + register) > * *unload*: removes a core idenitified by one of its aliases > **stops handling the Lucene index > **all SolrCore aliases are removed > * *reload*: recreate the core identified by one of its aliases > * *create*: create a core from a CoreDescriptor > **readies up the Lucene index > * *register*: registers all aliases of a SolrCore > > h4. SolrCore alias operations > * *swap*: swaps 2 aliases > **method: swap > * *alias*: creates 1 alias for a core, potentially unaliasing a > previously used alias > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > * *unalias*: removes 1 alias for a core > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > * *rename*: renames a core > h3. CoreAdminHandler: handles CoreContainer operations > * *load*/*create*: CoreContainer load > * *unload*: CoreContainer unload > * *reload*: CoreContainer reload > * *swap*: CoreContainer swap > * *alias*: CoreContainer alias > * *unalias*: CoreContainer unalias > * *rename*: CoreContainer rename > * *persist*: CoreContainer persist, writes the solr.xml > **stauts*: returns the status of all/one SolrCore -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: SolrPluginUtils.flattenBooleanQuery, dismax min-should-match
: Why is the dismax query being flattened? It would seem that because of : the limited syntax that DisMaxQParserPlugin employs, all you would ever get : is a one-level boolean query but I am probably missing something. Off the top of my head i really don't remember ... i'm sure there was a good reason ... either that or i was just really tired that day. -Hoss
Re: Writing Distributed Search Components
On Wed, Sep 24, 2008 at 4:42 PM, Grant Ingersoll <[EMAIL PROTECTED]> wrote: > 1. Can someone describe the stages (I think I know them, but there isn't > much docs on it)? The original SOLR-303 has the best description I think. 1) get ids of top docs, and merge them 2) get the stored fields from each shard, do highlighting > What if you feel you need a new stage? What would be the > method for adding it? (not saying I need one, but I wouldn't mind writing it > up on the Wiki page above). I think, I would just need to have my mythical > component return a value (in distributedProcess) that is in between the > values of whatever stage I wish to interject in, right? Right, that's why there are big numeric gaps between the existing stages. > The stages seem to > be very query-centric (which makes some sense) It's not a generic distributed computation platform :-) > 2. How does the modifyRequest piece work? I think the idea is that a > component later in the chain can piggyback onto an existing request, right? Both to piggyback, or modify. For example, the highlight component knows enough to turn off highlighting when appropriate. > So, perhaps in looking at my latest patch for S-651, I really should just > piggyback onto the retrieve docs request, right, that is likely coming from > the QueryComponent anyway? Sounds very reasonable. > 3. Anyone have suggestions on testing distributed SearchComponents? Right > now, S-651 is just calling the distributeProcess call directly, but I was > wondering whether we want to think about abstracting a test harness from the > TestDistributedSearch class that starts up multiple Jetty instances. > Thoughts? > > 4. Seems like we should put some effort into making the other components > support distributed operations, right? Is there an existing issue for > this? I see https://issues.apache.org/jira/browse/SOLR-785. Should we > handle it on an ad-hoc basis and just open issues for each one? separate issue for each one. They can be committed independently... no need to couple them. -Yonik
[jira] Updated: (SOLR-763) Support for LUCENE-1380 :: ShingleFilter.enablePositions
[ https://issues.apache.org/jira/browse/SOLR-763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mck SembWever updated SOLR-763: --- Attachment: SOLR-763-PositionFilterFactory.patch > Support for LUCENE-1380 :: ShingleFilter.enablePositions > > > Key: SOLR-763 > URL: https://issues.apache.org/jira/browse/SOLR-763 > Project: Solr > Issue Type: Improvement >Reporter: Mck SembWever > Fix For: 1.4 > > Attachments: SOLR-763-PositionFilterFactory.patch, > SOLR-763-PositionFilterFactory.patch, SOLR-763.patch > > > Patch so that ShingleFilterFactory can deserialise the > coterminalPositionIncrement property. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
