lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Will Johnson (JIRA)" <j...@apache.org>
Subject [jira] Updated: (SOLR-265) Make IndexSchema updateable in live system
Date Mon, 18 Jun 2007 18:26:26 GMT

     [ https://issues.apache.org/jira/browse/SOLR-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Will Johnson updated SOLR-265:
------------------------------

    Attachment: IndexSchemaReload.patch

updates to:

* solconfig.xml to register handler
* IndexSchema to add reload() method that clears() all internal data structures and calls
readconfig()
* a new o.a.s.handler.admin.IndexSchemaRequestHandler to trigger the updating



> Make IndexSchema updateable in live system
> ------------------------------------------
>
>                 Key: SOLR-265
>                 URL: https://issues.apache.org/jira/browse/SOLR-265
>             Project: Solr
>          Issue Type: Improvement
>          Components: update
>    Affects Versions: 1.3
>            Reporter: Will Johnson
>            Priority: Minor
>             Fix For: 1.3
>
>         Attachments: IndexSchemaReload.patch
>
>
> I've seen a few items on the mailing lists recently surrounding updating a schema on
the file system and not seeing the changes get propagated.  while I think that automatically
detecting schema changes on disk may be unrealistic, I do think it would be useful to be able
to update the schema without having to bounce the webapp.  the forthcoming patch adds a method
to SolrCore to do just that as well as a request handler to be able to call said method. 

> The patch as it exists is a straw man for discussion.  The one thing that concerned me
was making IndexScheam schema non-final in SolrCore.  I'm not quite sure why it needs to be
final to begin with so perhaps someone can shed some light on the situation.  Also, I think
it would be useful to be able to upload a schema through the admin GUI, have it persisted
to disk and then call relaodSchema()but that seemed like a good bit of effort for a patch
that might not even be a good idea.
> I'd also point out that this specific problem is one I've been trying to address recently
and while I think it could be solved with various dynamic fields the combination of all the
options for fields seemed to create too many variables to make useful dynamic name patterns.
> Thoughts?
> - will  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message