Re: Default operator
--- On Fri, 3/25/11, Brian Lamb wrote:
> From: Brian Lamb
> Subject: Default operator
> To: solr-user@lucene.apache.org
> Date: Friday, March 25, 2011, 10:54 PM
> Hi all,
>
> I know that I can change the default operator in two ways:
>
> 1) <*solrQueryParser defaultOperator*="AND|OR"/>
> 2) Add q.op=AND
>
> I'm wondering if it is possible to change the default
> operator for a
> specific field only? For example, if I use the URL:
>
> http://localhost:8983/solr/search/?q=animal:german
> shepherd&type:dog canine
>
> I would want it to effectively be:
>
> http://localhost:8983/solr/search/?q=animal:german AND
> shepherd&type:dog OR
> canine
>
> Other than parsing the URL before I send it out, is there a
> way to do this?
With http://wiki.apache.org/solr/LocalParams there can be some ways:
fq={!q.op=OR df=type}dog canine&q=german shepherd
Re: Default operator
The other way could be to extend the SolrQueryParser to read a per field default operator in the solr config file. Then it should be possible to override this functions : setDefaultOperator getDefaultOperator and this two which are using the default operator : getFieldQuery addClause The you just have to declare it in the solr config file and configure your default operators. Ludovic. - Jouve France. -- View this message in context: http://lucene.472066.n3.nabble.com/Default-operator-tp2732237p2734931.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: solr on the cloud
Thanks, Jason, this looks very relevant! On Fri, Mar 25, 2011 at 11:26 PM, Jason Rutherglen < jason.rutherg...@gmail.com> wrote: > Dmitry, > > If you're planning on using HBase you can take a look at > https://issues.apache.org/jira/browse/HBASE-3529 I think we may even > have a reasonable solution for reading the index [randomly] out of > HDFS. Benchmarking'll be implemented next. It's not production > ready, suggestions are welcome. > > Jason > > On Fri, Mar 25, 2011 at 2:03 PM, Dmitry Kan wrote: > > Hi Otis, > > > > Thanks for elaborating on this and the link (funny!). > > > > I have quite a big dataset growing all the time. The problems that I > start > > facing are pretty much predictable: > > 1. Scalability: this inludes indexing time (now some days!, better hours > or > > even minutes, if that's possible) along with handling the rapid growth > > 2. Robustness: the entire system (distributed or single server or > anything > > else) should be fault-tolerant, e.g. if one shard goes down, other > catches > > up (master-slave scheme) > > 3. Some apps that we run on SOLR are pretty computationally demanding, > like > > faceting over one+bi+trigrams of hundreds of millions of documents (index > > size of half a TB) ---> single server with a shard of data does not seem > to > > be enough for realtime search. > > > > This is just for a bit of a background. I agree with you on that hadoop > and > > cloud probably best suit massive batch processes rather than realtime > > search. I'm sure, if anyone out there made SOLR shine throught the cloud > for > > realtime search over large datasets. > > > > By "SOLR on the cloud (e.g. HDFS + MR + cloud of > > commodity machines)" I mean what you've done for your customers using > EC2. > > Any chance, the guidlines/articles for/on setting indices on HDFS are > > available in some open / paid area? > > > > To sum this up, I didn't mean to create a buzz on the cloud solutions in > > this thread, just was wondering what is practically available / going on > in > > SOLR development in this regard. > > > > Thanks, > > > > Dmitry > > > > > > On Fri, Mar 25, 2011 at 10:28 PM, Otis Gospodnetic < > > otis_gospodne...@yahoo.com> wrote: > > > >> Hi Dan, > >> > >> This feels a bit like a buzzword soup with mushrooms. :) > >> > >> MR jobs, at least the ones in Hadoopland, are very batch oriented, so > that > >> wouldn't be very suitable for most search applications. There are some > >> technologies like Riak that combine MR and search. Let me use this > funny > >> little > >> link: http://lmgtfy.com/?q=riak%20mapreduce%20search > >> > >> > >> Sure, you can put indices on HDFS (but don't expect searches to be > fast). > >> Sure > >> you can create indices using MapReduce, we've done that successfully for > >> customers bringing long indexing jobs from many hours to minutes by > using, > >> yes, > >> a cluster of machines (actually EC2 instances). > >> But when you say "more into SOLR on the cloud (e.g. HDFS + MR + cloud > of > >> commodity machines)", I can't actually picture what precisely you > mean... > >> > >> > >> Otis > >> --- > >> Sematext :: http://sematext.com/ :: Solr - Lucene - Nutch > >> Lucene ecosystem search :: http://search-lucene.com/ > >> > >> > >> > >> - Original Message > >> > From: Dmitry Kan > >> > To: solr-user@lucene.apache.org > >> > Cc: Upayavira > >> > Sent: Fri, March 25, 2011 8:26:33 AM > >> > Subject: Re: solr on the cloud > >> > > >> > Hi, Upayavira > >> > > >> > Probably I'm confusing the terms here. When I say "distributed > faceting" > >> I'm > >> > more into SOLR on the cloud (e.g. HDFS + MR + cloud of commodity > >> machines) > >> > rather than into traditional multicore/sharded SOLR on a single or > >> multiple > >> > servers with non-distributed file systems (is that what you mean when > >> you > >> > refer to "distribution of facet requests across hosts"?) > >> > > >> > On Fri, Mar 25, 2011 at 1:57 PM, Upayavira wrote: > >> > > >> > > > >> > > > >> > > On Fri, 25 Mar 2011 13:44 +0200, "Dmitry Kan" < > dmitry@gmail.com> > >> > > wrote: > >> > > > Hi Yonik, > >> > > > > >> > > > Oh, this is great. Is distributed faceting available in the > trunk? > >> What > >> > > > is > >> > > > the basic server setup needed for trying this out, is it cloud > with > >> HDFS > >> > > > and > >> > > > SOLR with zookepers? > >> > > > Any chance to see the related documentation? :) > >> > > > >> > > Distributed faceting has been available for a long time, and is > >> > > available in the 1.4.1 release. > >> > > > >> > > The distribution of facet requests across hosts happens in the > >> > > background. There's no real difference (in query syntax) between a > >> > > standard facet query and a distributed one. > >> > > > >> > > i.e. you don't need SolrCloud nor Zookeeper for it. (they may > provide > >> > > other benefits, but you don't need them for distributed faceting). > >> > > > >> > > Upayavira > >> > > > >> > > >
DIH relating multiple DataSources
Hi All, I'm a newbie to SOLR and is hoping to get some help. I was able to get DIH to work with one datasource. What I'm trying to achieve is using two datasources to build my document. Below is my data-config: If the above possible? I can't seem to get my "title" field above populated from a second datasource but the fields identified in my rootEntity using the first datasource works perfectly fine. Thanks, Jeff TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
utf-8 is not so much everywhere
Hello group, this message is a word of warning and plea to wiki writers. Reading the wiki and documentation in general, there seems to be an accepted consensus that most in SOLR is working in utf-8. To my opinion this is absolutely good. But this may be a remain of the times. Several efforts seem to have been done to revert to more tolerant defaults. Believing the wiki, I suspected all sorts of broken things in my indexer pipeline. At the end, thanks to my dear Luke desktop application, I realized that it was just the defaults that were wrong: both the the Velocity response-writer was using iso-8859-1. With velocity, you just need text/html; charset=utf-8 (the default seems to be text/html and not output any form of charset) Others may be different. I don't see a wiki page specialized to that. paul
Re: New PHP API for Solr (Logic Solr API)
Lukas, How do you think it should have been designed? Most libraries are not going to have all the features that you need and while there may be features about the library that you do not like others may really appreciate them being there. As I said earlier in an earlier email a couple of months ago, the SolrQuery:set(), get() and add() methods do exist for you to use if you prefer not to use the feature specific methods in the SolrQuery class, thats the beauty of it. The PECL extension was something I designed to use on a personal project and it was really helpful in managing faceted search and other features that solr has to offer. I decided to share it with the PHP community because I felt others might need similar functionality. So it is possible that they may have been use cases that applied to my project that may not be applicable to yours I initially used the SolrJ API to access Solr via Java and then when I had a PHP project I decided to use something similar to SolrJ but at the time there was nothing similar in the PHP realm http://lucene.apache.org/solr/api/org/apache/solr/client/solrj/package-summary.html A review of the SolrJ API will offer more explanations on some of the features present in the PECL API I will really love to get feedback from others about the design of the PECL library about any other missing or extraneous features Thanks. On Mon, Mar 7, 2011 at 4:04 AM, Lukas Kahwe Smith wrote: > > On 07.03.2011, at 09:43, Stefan Matheis wrote: > > > Burak, > > > > what's wrong with the existing PHP-Extension > > (http://php.net/manual/en/book.solr.php)? > > > the main issue i see with it is that the API isn't "designed" much. aka it > just exposes lots of features with dedicated methods, but doesnt focus on > keeping the API easy to overview (aka keep simple things simple and make > complex stuff possible). at the same time fundamental stuff like quoting are > not covered. > > that being said, i do not think we really need a proliferation of solr > API's for PHP, even if this one is based on PHP 5.3 (namespaces etc). btw > there is already another PHP 5.3 based API, though it tries to also unify > other Lucene based API's as much as possible: > https://github.com/dstendardi/Ariadne > > regards, > Lukas Kahwe Smith > m...@pooteeweet.org > > > > -- °O° "Good Enough" is not good enough. To give anything less than your best is to sacrifice the gift. Quality First. Measure Twice. Cut Once. http://www.israelekpo.com/
