Polish stemming schema.xml
Hi everybody, I'm working now on solr implementation for a multi-language website. I've found a lot of language managed by solr like, japon, greek . spanish .. But I didn't found anything about Polish. Can you help me please ? fieldType name=text_ja class=solr.TextField tokenizer class=org.apache.lucene.analysis.cjk.CJKTokenizer / analyzer class=org.apache.lucene.analysis.cjk.CJKAnalyzer/ /fieldType OR fieldtype name=text_es class=solr.TextField analyzer tokenizer class=solr.StandardTokenizerFactory/ filter class=solr.StandardFilterFactory/ filter class=solr.ISOLatin1AccentFilterFactory/ filter class=solr.LowerCaseFilterFactory/ filter class=solr.SnowballPorterFilterFactory language=Spanish / /analyzer /fieldtype Thanks for your help. Wish you a nice day, Sunny -- View this message in context: http://www.nabble.com/Polish-stemming-schema.xml-tp19450974p19450974.html Sent from the Solr - Dev mailing list archive at Nabble.com.
Re: Configuration features, Solr2/Spring Solr1.x future
Now, that's clearer! :-) Erik Hatcher wrote: actually, configuration _should_ be code :) The above shows a way to programmatically create ... ...affect settings could be done without resorting to XML gymnastics. ... dynamic configuration... it's that XML middleman that annoys me. So, if we were to have Java classes equivalents of what is contained in solr.xml, schema.xml or solrconfig.xml, would that be enough (or at least a good enough first step)? Say a SchemaDescriptor and SolrConfigDescriptor where all the XML attributes nodes would be transformed into their Java equivalents, would this fit your dynamic needs ? This alone would allow to completely configure a Solr installation without any file, only code. And serializing in from XML to instances of these would still be possible; this could almost imply that XML configuration would become a contrib. For that matter, even Spring configuration whether programmatic or XML could be a contrib. And this would pave the way to externalize integration/deployment features. Am I getting this more or less correctly ? -- View this message in context: http://www.nabble.com/Configuration-features%2C-Solr2-Spring---Solr1.x-future-tp19435196p19454119.html Sent from the Solr - Dev mailing list archive at Nabble.com.
[jira] Updated: (SOLR-561) Solr replication by Solr (for windows also)
[ https://issues.apache.org/jira/browse/SOLR-561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Akshay K. Ukey updated SOLR-561: Comment: was deleted Solr replication by Solr (for windows also) --- Key: SOLR-561 URL: https://issues.apache.org/jira/browse/SOLR-561 Project: Solr Issue Type: New Feature Components: replication Affects Versions: 1.4 Environment: All Reporter: Noble Paul Assignee: Shalin Shekhar Mangar Fix For: 1.4 Attachments: deletion_policy.patch, SOLR-561-core.patch, SOLR-561-full.patch, SOLR-561-full.patch, SOLR-561-full.patch, SOLR-561.patch, SOLR-561.patch, SOLR-561.patch, SOLR-561.patch, SOLR-561.patch, SOLR-561.patch The current replication strategy in solr involves shell scripts . The following are the drawbacks with the approach * It does not work with windows * Replication works as a separate piece not integrated with solr. * Cannot control replication from solr admin/JMX * Each operation requires manual telnet to the host Doing the replication in java has the following advantages * Platform independence * Manual steps can be completely eliminated. Everything can be driven from solrconfig.xml . ** Adding the url of the master in the slaves should be good enough to enable replication. Other things like frequency of snapshoot/snappull can also be configured . All other information can be automatically obtained. * Start/stop can be triggered from solr/admin or JMX * Can get the status/progress while replication is going on. It can also abort an ongoing replication * No need to have a login into the machine * From a development perspective, we can unit test it This issue can track the implementation of solr replication in java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Configuration features, Solr2/Spring Solr1.x future
Erik Hatcher wrote:
I like how you summarized my post :)
Trying to get to the gist of it. ;)
Erik Hatcher wrote:
I haven't given any consideration to exactly what kind of API changes
are needed, but certainly being able to build an IndexSchema without
XML being involved would be the result of such a refactoring.
Let's say hypothetically that a stubborn contributor issues a patch along
those lines: {Solr,SolrConfig,SolrSchema}Descriptor classes that capture
what is currently defined through XML in a Java way, uses JXPath to avoid
rewriting the init code that does exist and some parsers so the current XML
could still be used to instantiate those classes, would that be considered
an acceptable base?
Erik Hatcher wrote:
Though not entirely sure about all configuration being a contrib.
Practically speaking we still want Solr to have some kind of defacto
out of the box experience...
Ok, contrib was pushing it a little but say a different jar; the core Solr
code in one and the default configurator in another ?
Erik Hatcher wrote:
Solr is a search server, and (re)inventing configurators really belongs
elsewhere.
Gotcha.
--
View this message in context:
http://www.nabble.com/Configuration-features%2C-Solr2-Spring---Solr1.x-future-tp19435196p19457564.html
Sent from the Solr - Dev mailing list archive at Nabble.com.
[VOTE] Release Solr 1.3.0
Proposed artifacts are at http://people.apache.org/~gsingers/solr/ 1.3.0/ Please download and do your thing to check out that it works. See also https://issues.apache.org/jira/browse/SOLR/fixforversion/12312486 +1 to release, 0 if you're indifferent, -1 if you see something wrong. We need 3 PMC member votes to release. Since we have at least 3 PMC members as Solr committers, this shouldn't be a problem. Vote is open for 3 days. Whew. Cheers, Grant
Re: [VOTE] Release Solr 1.3.0
On Fri, Sep 12, 2008 at 11:36 AM, Grant Ingersoll [EMAIL PROTECTED] wrote: +1 to release, 0 if you're indifferent, -1 if you see something wrong. We need 3 PMC member votes to release. Since we have at least 3 PMC members as Solr committers, this shouldn't be a problem. Vote is open for 3 days. Non PMC members (and non committers) should also feel free to vote. Your voice does matter! -Yonik
Re: [VOTE] Release Solr 1.3.0
I'm +0 for a release. Quite a lot of things have been changed/added in the last couple of weeks and I think more people need to work with them and test. Also it seems to me that the distributed search stuff isn't quite ready to be used in production yet -- you can't just move from a non-distributed setup to a distributed one and expect everything to work as before. I'm not even talking about bugs here, but also about missing features/different behaviour (see e.g. SOLR-764). Lars
