Re: Binary fields in index

Binary fields can be stored, but not indexed. -Yonik Now hiring -- http://tinyurl.com/7m67g On 9/26/05, Fredrik Andersson [EMAIL PROTECTED] wrote: I was hoping to avoid the overhead of encoding/decoding, but it looks like I'll have to do that :( While on the topic, I noticed in the Field

Re: Infrastructure for large Lucene index

On 10/6/06, James [EMAIL PROTECTED] wrote: Our indexes are, in aggregate across our various collections, even larger than you need. We use Remote ParalellMultiSearcher, with some custom modifications (and we are in the process of making more) I'm looking into adding some form of distributed

Re: Infrastructure for large Lucene index

On 10/6/06, Slava Imeshev [EMAIL PROTECTED] wrote: -- James [EMAIL PROTECTED] wrote: If the index is broken into multiple shards then we need multiple copies of each shard, and some way of loadbalancing and failing over amongst copies of shards. Yep. Unfortunately it's not simple, but

Re: [PROPOSAL] index server project

On 10/18/06, Doug Cutting [EMAIL PROTECTED] wrote: Does this make sense? Does it sound like it would be useful to Solr? To Nutch? To others? Who would be interested and able to work on it? Rather than holding my tounge until I wrap my head around all the issues, I'll say that I'm definitely

Re: [PROPOSAL] index server project

On 10/19/06, Steven Parkes [EMAIL PROTECTED] wrote: You mention partitioning of indexes, though mostly around delete. What about scalability of corpus size? Definitely in scope. Solr already has scalability of search volume via searchers behind of a load balancer all getting their index from

Re: Searching by bit masks

On 11/9/06, ltaylor.employon [EMAIL PROTECTED] wrote: I am currently evaluating Lucene to see if it would be appropriate to replace my company's current search software. So far everything has been looking great, however there is one requirement that I am not too certain about. What we need to

Solr graduates and joins Lucene as sub-project

Solr has just graduated from the Incubator, and has been accepted as a Lucene sub-project! Thanks to all the Lucene and Solr users, contributors, and developers who helped make this happen! I have a feeling we're just getting started :-) -Yonik

Re: how to control the disk size of the indices

On Mon, Mar 24, 2008 at 9:34 PM, Otis Gospodnetic [EMAIL PROTECTED] wrote: Hi Yannis, I don't think there is anything of that sort in Lucene, but this shouldn't be hard to do with a process outside Lucene. Of course. optimizing an index increases its size temporarily, so your external

Re: [ACUS09] Proposed Schedule

On Tue, Jul 14, 2009 at 4:53 PM, Uwe Schindleru...@thetaphi.de wrote: NumericRangeQuery is not only geographical search... So it would also cover other directions: Things I can do with Lucene additionally to full text search, that could be done before only with RDBMS and/or PostGIS...: Do full

Re: [VOTE] Release Apache Lucene Java 2.9.1

On Mon, Oct 26, 2009 at 12:43 PM, Uwe Schindler u...@thetaphi.de wrote: Looks good. One thing: In Mark's artifacts, he changed the common-build.xml to not have -dev in the version before the release. You can see this in SVN. I am fine with having -dev in the source artefact, because if

Re: [VOTE] Release Solr 1.4.0

Hmmm, weren't you going to update the version numbers to 1.4.1-dev like we just discussed in the other thread? That way if someone changes some of the solr source from the download and recompiles, they don't get a version number of 1.4.0 -Yonik http://www.lucidimagination.com On Mon, Oct 26,

Re: [VOTE] Release Solr 1.4.0

On Mon, Oct 26, 2009 at 9:58 PM, Grant Ingersoll gsing...@apache.org wrote: OK, take two is up in the same place.  Please vote. I'm seeing emptiness at http://people.apache.org/~gsingers/solr/1.4.0/ -Yonik http://www.lucidimagination.com On Oct 26, 2009, at 6:15 PM, Grant Ingersoll wrote:

Re: [VOTE] Release Solr 1.4.0

On Thu, Oct 29, 2009 at 8:49 AM, Uwe Schindler u...@thetaphi.de wrote: Yes, it's too bad! But you will replace the lucene jars in the artifacts before releasing? Because it would not be good to have jar files with version 2.9.1 in the package that are not the officially released 2.9.1

Re: [VOTE] Release Solr 1.4.0

, 2009 at 8:59 AM, Grant Ingersoll gsing...@apache.orgwrote: Yeah, unfortunately, I think we need to use the new Jars. On Oct 29, 2009, at 8:52 AM, Yonik Seeley wrote:  On Thu, Oct 29, 2009 at 8:49 AM, Uwe Schindler u...@thetaphi.de wrote: Yes, it's too bad! But you will replace the lucene

Re: [VOTE] Release Apache Lucene Java 2.9.1, take 3

On Thu, Oct 29, 2009 at 7:27 PM, Michael McCandless luc...@mikemccandless.com wrote: OK, let's try this again! I've built new release artifacts from svn rev 831145 (on the 2.9 branch), here:  http://people.apache.org/~mikemccand/staging-area/rc3_lucene2.9.1/ Changes are here:  

Re: [spatial] Cartesian Tiers nomenclature

On Tue, Dec 29, 2009 at 7:13 PM, Marvin Humphrey mar...@rectangular.com wrote: ... but for this algorithm, different rasterization resolutions need not proceed by powers-of-two. Indeed - one way to further generalize would be to use something like Lucene's trie-based Numeric field, but with a

Re: Factor out a standalone, shared analysis package for Nutch/Solr/Lucene?

I've started to think that a merge of Solr and Lucene would be in the best interest of both projects. Recently, Solr as pulled back from using Lucene trunk (or even the latest version), as the increased amount of change between releases (and in-between releases) made it impractical to deal with.

Re: Factor out a standalone, shared analysis package for Nutch/Solr/Lucene?

On Fri, Feb 26, 2010 at 5:15 PM, Steven A Rowe sar...@syr.edu wrote: On 02/24/2010 at 2:20 PM, Yonik Seeley wrote: I've started to think that a merge of Solr and Lucene would be in the best interest of both projects. The Sorlucene :) merger could be achieved virtually, i.e. via policy, rather

[VOTE] merge lucene/solr development

Many Lucene/Solr committers think that merging development would be a benefit to both projects. Separate downloads would remain (among other things), so end users would not be impacted (except for higher quality products over time). Since this is a change to Lucene/Solr project development, I'd

Re: [VOTE] merge lucene/solr development

On Wed, Mar 3, 2010 at 7:41 PM, Mark Miller markrmil...@gmail.com wrote: I'm only for the merge with aligned releases - its the only way Solr can really stay on Lucene trunk happily. Aligned releases are also my biggest worry (and part of why I initially leaned against such a merge), but

Re: [VOTE] merge lucene/solr development

+1 Great idea! :-) -Yonik On Wed, Mar 3, 2010 at 5:42 PM, Yonik Seeley yo...@apache.org wrote: Many Lucene/Solr committers think that merging development would be a benefit to both projects. Separate downloads would remain (among other things), so end users would not be impacted (except

Re: [VOTE] Merge the development of Solr/Lucene (take 2)

+1 -Yonik On Thu, Mar 4, 2010 at 4:33 PM, Michael McCandless luc...@mikemccandless.com wrote: A new vote, that slightly changes proposal from last vote (adding only that Lucene can cut a release even if Solr doesn't):  * Merging the dev lists into a single list.  * Merging committers.  *

[VOTE] merge lucene/solr development (take 3)

Apoligies in advance for calling yet another vote, but I just wanted to make sure this was official. Mike's second VOTE thread could probably technically stand on it's own (since it included PMC votes), but given that I said in my previous VOTE thread that I was just polling Lucene/Solr committers

Re: [VOTE] merge lucene/solr development (take 3)

On Mon, Mar 8, 2010 at 9:22 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: For completeness from the VOTE on private@ It's called private for a reason. -Yonik

Re: [VOTE] merge lucene/solr development (take 3)

On Mon, Mar 8, 2010 at 9:49 PM, Michael Busch busch...@gmail.com wrote: Question: Is it sufficient to have more +1s than -1s for this vote to pass? 3 +1s and more +1s than -1s is sufficient. I thought for votes as significant as this one a -1 veto is a showstopper? It's not really tied to

Re: [VOTE] merge lucene/solr development (take 3)

I think the problem is political - and that leads to both technical and political problems. We came up with a largely political solution that should solve both. We can't have a one way street of pulling everything interesting out of Solr for Lucene, or poaching, or expanding Lucene's domain while

Re: [VOTE] merge lucene/solr development (take 3)

On Tue, Mar 9, 2010 at 9:48 AM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: I have built 10s of projects that have simply used Lucene as an API and had no need for Solr, and I've built 10s of projects where Solr made perfect sense. So, I appreciate their separation. As does

Re: [VOTE] merge lucene/solr development (take 3)

On Tue, Mar 9, 2010 at 11:00 AM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: However, like I said it seems to be like the discussion of the real issues is only happening recently over the past few days. This certainly isn't new territory for lucene/solr devs though - the

Re: [VOTE] merge lucene/solr development (take 3)

On Tue, Mar 9, 2010 at 11:35 AM, Michael Busch busch...@gmail.com wrote: No matter if this dev-merge vote passes or not, we still want a separate analysis module, right? No. That's the point of the dev merge - to allow free movement of source code that benefits both projects. -Yonik

Re: [VOTE] merge lucene/solr development (take 3)

Thanks everyone, this vote has passed. A bit more contentious of a PMC vote than usual, but the committer vote was clear. -Yonik On Mon, Mar 8, 2010 at 9:11 PM, Yonik Seeley ysee...@gmail.com wrote: Apoligies in advance for calling yet another vote, but I just wanted to make sure

Re: [VOTE] merge lucene/solr development (take 3)

On Sun, Mar 14, 2010 at 11:02 AM, Otis Gospodnetic otis_gospodne...@yahoo.com wrote: Would it be correct to say that a subset of Lucene/Solr committers discussed the proposal internally/offline (i.e. not on MLs) before proposing it? Nope. Where did this idea come from? I'm quite sure my

Re: [VOTE] merge lucene/solr development (take 3)

On Sun, Mar 14, 2010 at 2:36 PM, Otis Gospodnetic otis_gospodne...@yahoo.com wrote: if I understand things correctly, poaching is only needed when the code is not committed in the right project/location to begin with. That is the problem though - Solr should be allowed to keep whatever code

Re: [VOTE] merge lucene/solr development (take 3)

On Sun, Mar 14, 2010 at 2:58 PM, Otis Gospodnetic otis_gospodne...@yahoo.com wrote: Would it make sense to think of Solr as one such Lucene module? In other words, don't even bother with merging just the -dev lists, but really just merge everything.  In that case Solr's relationship with

Re: Branding Solr+Lucene

On Mon, Mar 22, 2010 at 2:20 PM, Ryan McKinley ryan...@gmail.com wrote: I'm confused... what is the need for a new name?  The only place where there is a conflict is in the top level svn tree... Agree, no need to re-brand. What about something general like:

Re: New LuSolr trunk (was: RE: (LUCENE-2297) IndexWriter should let you optionally enable reader pooling)

For Solr, we can just move the current trunk to a 15 branch. -Yonik On Tue, Mar 23, 2010 at 9:39 AM, Grant Ingersoll gsing...@apache.org wrote: On Mar 22, 2010, at 8:27 AM, Uwe Schindler wrote: Hi all, the discussion where to do the development after the merge, now gets actual: Currently

Re: [DISCUSS] Lucene Java - Lucene Core

On Mon, Nov 8, 2010 at 1:02 PM, Uwe Schindler u...@thetaphi.de wrote: Die, Contrib, die! We will hopefully only have modules soon? +1 to Lucene Core, Lucene Modules and Solr. As qualifier we can use for Java to differentiate from .NET. But in my opinion, all others should be separate

[VOTE] Create Solr TLP

A single merged project works only when people are relatively on the same page, and when people feel it's mutually beneficial. Recent events make it clear that that is no longer the case. Improvements to Solr have been recently blocked and reverted on the grounds that the new functionality was

Re: SOLR Sorting algorithm

When sorting, ties are broken by the internal document id. This gives us a stable (if somewhat arbitrary) sort ordering. If you want score to be the tiebreaker, you can specify it as the secondary sort. -Yonik http://www.lucene-eurocon.com - The Lucene/Solr User Conference On Tue, Sep 6, 2011

Re: SOLR Sorting algorithm

On Tue, Sep 6, 2011 at 4:48 PM, BrianK brian.krue...@bonton.com wrote: by internal document id you are referring to a field that is not visible to us.  We have an id field, I assume this is not the document id field you are talking about.  Assuming document id is not available to us, is it

Re: Welcome Alan Woodward as Lucene/Solr committer

Congrats and welcome, Alan! -Yonik http://lucidworks.com On Wed, Oct 17, 2012 at 1:36 AM, Robert Muir rcm...@gmail.com wrote: I'm pleased to announce that the Lucene PMC has voted Alan as a Lucene/Solr committer. Alan has been contributing patches on various tricky stuff: positions

Re: Welcome David Smiley to the PMC

On Mon, Mar 18, 2013 at 10:28 AM, Smiley, David W. dsmi...@mitre.org wrote: Thanks Steve, and to the rest of the PMC members! I hope to see many of you at Lucene/Solr Revolution in May. +1 Welcome! -Yonik http://lucidworks.com

Re: [ANNOUNCE] Apache Solr 7.1.0 released

It pointed to 7.1.0 for me perhaps a browser cache issue? Anyway, you can go directly as well: http://www.apache.org/dyn/closer.lua/lucene/solr/7.1.0 -Yonik On Tue, Oct 17, 2017 at 11:25 AM, Susheel Kumar wrote: > Thanks, Shalin. > > But the download mirror still has