Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_60-ea-b10) - Build # 9841 - Failure!

Hmmm; I’ll fix this ASAP On 3/18/14, 11:53 PM, "Policeman Jenkins Server" wrote: >Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/9841/ >Java: 32bit/jdk1.7.0_60-ea-b10 -client -XX:+UseG1GC > >1 tests failed. >FAILED: >org.apache.lucene.spatial.prefix.SpatialOpRecursivePrefixTree

Re: [jira] [Commented] (LUCENE-5451) Update Spatial4j to 0.4.1

Trunk & branch_4x & lucene_solr_4_7 have the new change for Spatial4j 0.4.1 committed. JIRA is down. On 2/18/14, 4:39 PM, "David Smiley (JIRA)" wrote: > >[ >https://issues.apache.org/jira/browse/LUCENE-5451?page=com.atlassian.jira. >plugin.system.issuetabpanels:comment-tabpanel&focusedComm

Re: Ensuring a test uses a codec supporting DocValues

Thanks Simon. On 2/17/14, 4:50 AM, "Simon Willnauer" wrote: >just put this annotation at the class level: > >@SuppressCodecs("Lucene3x") > >simon > >On Mon, Feb 17, 2014 at 4:56 AM, Smiley, David W. >wrote: >> I wrote a test that require

Re: Welcome Anshum Gupta as Lucene/Solr Committer!

Cool! Welcome to the team, Anshum. ~ David From: Anshum Gupta mailto:ans...@anshumgupta.net>> Reply-To: "dev@lucene.apache.org Dev" mailto:dev@lucene.apache.org>> Date: Sunday, February 16, 2014 at 10:14 PM To: "dev@lucene.apache.org De

Ensuring a test uses a codec supporting DocValues

I wrote a test that requires DocValues. It failed on me once because of the Codec randomization chose Lucene3x which doesn’t support DocValues. What’s the best way to adjust my test to assure this doesn’t happen? What I ended up doing was this: indexWriterConfig.setCodec( _TestUtil.alwaysDocVal

Re: Should Postings codec be Solr's default for 'id' ?

(e.g. specify >to pulse things with docfreq < 3 or something like that), but its >redundant and probably actually less efficient for the "id field" case >than just using the default codec. > >On Wed, Nov 20, 2013 at 7:44 AM, Smiley, David W. >wrote: >> The Postings co

Should Postings codec be Solr's default for 'id' ?

The Postings codec seems ideal for primary key fields. Shouldn't Solr use this for its 'id' field by default? ~ David

New "MATF" relevance model supposedly pretty good

I noticed this new published research on relevance ranking, published in SIGIR '13: "A novel TF-IDF weighting scheme for effective ranking". It is supposedly better than the other popular ranking algorithms like TF-IDF, BM-25, etc. http://dl.acm.org/citation.cfm?id=2484070 The author calls it "M

RE: Documentation on the new compressed DocIdSet implementations

Awesome detail; thanks Adrien! I love the charts. Since the list is searchable, others looking for this information will hopefully find it. I'm excited about the prospects of Lucene choosing an optimal postings format dependent on term density -- way cool! (or as we say in Massachusetts: "Wic

Documentation on the new compressed DocIdSet implementations

Lucene has got some new compressed DocIdSet implementations that are technically very interesting and exciting: PForDeltaDocIdSet, WAH8DocIdSet, EliasFanoDocIdSet, … any more? Yet it's difficult (at least for me) to understand their pros/cons to know when to pick amongst them. They all seem g

Re: VOTE: RC2 Release apache-solr-ref-guide-4.4.pdf

Re-affirming my +1 against the sha1, which checks out against my download. On 7/25/13 8:57 PM, "Chris Hostetter" wrote: > >: : Please VOTE to release the following PDF as >apache-solr-ref-guide-4.4.pdf >: : >: : https://people.apache.org/~hossman/apache-solr-ref-guide-4.4_RC2.pdf > >For complet

Re: VOTE: RC1 Release apache-solr-ref-guide-4.4.pdf

On 7/25/13 4:29 AM, "Steve Rowe" wrote: > >I also noticed that David Smiley made a bunch of modifications, AFAICT to >spatial and related topics, and it would be good to include those. Yes, the spatial page needed an overhaul; I think it's much better now. It was a refactor to better express t

Re: [JENKINS] Lucene-Solr-4.x-Linux (64bit/jdk1.8.0-ea-b98) - Build # 6591 - Failure!

I'll look into this. On 7/21/13 1:04 PM, "Policeman Jenkins Server" wrote: >Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/6591/ >Java: 64bit/jdk1.8.0-ea-b98 -XX:+UseCompressedOops -XX:+UseParallelGC > >1 tests failed. >FAILED: >org.apache.lucene.spatial.prefix.SpatialOpRecursiveP

Re: JIRA "spatial" component for Solr

;s >not there yet. > >- Mark > >On Jun 17, 2013, at 10:44 AM, Steve Rowe wrote: > >> +1 >> >> On Jun 17, 2013, at 10:34 AM, "Smiley, David W." >>wrote: >> >>> For tracking purposes, I'd like to add a JIRA component named &g

JIRA "spatial" component for Solr

For tracking purposes, I'd like to add a JIRA component named "spatial", and then subsequently bulk-edit issues which I believe pertain to spatial in Solr. By doing so, I want to more easily be aware of spatial issues in Solr reported in JIRA. I'll do it within a few days unless there are objec

Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_21) - Build # 6159 - Still Failing!

Reported the bug with a narrow test case: https://issues.apache.org/jira/browse/LUCENE-5062 I'm currently looking into a fix. In the mean time the existing tests should very, very rarely hit this. The other failures were on 4x, which failed because of a former problem in the test that was fixed i

Re: [JENKINS] Lucene-Solr-4.x-Linux (32bit/jdk1.6.0_45) - Build # 6066 - Still Failing!

So it turns out that most test failures were on the 4x branch and that's because I forgot to apply a test bug to the 4x branch last month (doh!). But there is still a bug for me to find because trunk failed, and I needed the -Dtests.multiplier=3 to reproduce it. Thanks Dawid. ~ David On 6/15/13

Re: Possible problem with RAMDirectory; tips please

On 4/8/13 5:05 PM, "Dawid Weiss" wrote: >> thought I checked for that but apparently I got confused. I do find it >> disconcerting that the random seed can get incremented by >> LuceneTestCase.newDirectory() a different number of times depending on >> wether or not -Dtests.seed has been set. >

Re: Welcome David Smiley to the PMC

Thanks Steve, and to the rest of the PMC members! I hope to see many of you at Lucene/Solr Revolution in May. ~ David On 3/18/13 10:13 AM, "Steve Rowe" wrote: >I'm pleased to announce that David Smiley has accepted the PMC's >invitation to join. > >Welcome David! > >- Steve >--

Re: IntHashSet, SentinelIntSet, SortedIntDocSet, ...

Thanks for that advise; I trust your judgement! Do you have an opinion on copying IntHashSet directly to Lucene-core or some other approach? On 1/30/13 3:59 PM, "Dawid Weiss" wrote: >> IntHashSet and SentinalIntSet. However it computes a hash of the id >>using >> MurMurHash3, which I think is

IntHashSet, SentinelIntSet, SortedIntDocSet, ...

I'm looking for some advise on data structures, perhaps resulting in moving/consolidating some existing ones used across Lucene/Solr. I'm working on a Filter implementation in the spatial module that needs to collect a set of docids. I could use new OpenBitSet(maxdoc) (or FixedBitSet) of cours

Proposal to move/hide the general@lucene list

The gene...@lucene.apache.org list is often misused for help on Lucene or Solr that belong on their respective lists. I'm okay with the list being discontinued. If people are not okay with that, then I propose modifying the page where people currently discover the list so that they aren't like

Re: Solr faceting vs. Lucene faceting

I second this use-case. This is my only concern with Solr faceting — Solr's UnInvertedField on the search index to discover frequently used words. It doesn't scale well. Shai; do you think this would scale? FWIW one of my indexes with only 300k docs has ~3.1M terms — not a lot but it's a nu

Re: ant precommit; annoyed with "checkout is dirty"

How about doing the dirty checks on sub-directories only? This way I can keep the random .patch files & miscellany around in the root. The IDE files are a special circumstance for my setup because I use symbolic links to the IDE files in dev-tools so that I can easily see how my IDE setup is d

Re: Spatial4j dependency in lucene 4.0.0, final

On Nov 15, 2012, at 4:09 PM, mailto:karl.wri...@nokia.com>> wrote: I am willing to assist to some extent with spatial4j, if that is yours. FYI the Spatial4j dev list is here: http://spatial4j.16575.n6.nabble.com It changed significantly from 0.2 to 0.3, and not just in the area of package

Re: Spatial4j dependency in lucene 4.0.0, final

Hi Karl! You say that the dependency isn't versioned, but all dependencies are versioned. If you say it's unversioned because you can't see the version in the pom for lucene-spatial, that's because it's specified in the section of the parent pom for lucene itself. Lucene 4.0.0-BETA depends

Re: Changes as we approach v4

On Sep 21, 2012, at 4:51 PM, Robert Muir wrote: > On Fri, Sep 21, 2012 at 4:20 PM, david.w.smi...@gmail.com > wrote: >> compatibility concern to changes until v4 is actually released. In >> your opinion, is it too late to do class renames in this area? -- >> LUCENE-4374 is about renaming TwoDou

Spatial field names in Solr

This past Sunday I added 3 spatial field types to Solr in SOLR-3304: SpatialTwoDoublesFieldType, SpatialRecursivePrefixTreeFieldType and SpatialTermQueryPrefixTreeFieldType. Eventually there will also be a SpatialBBoxFieldType following this naming convention. These are named in a consistent

Re: svn commit: r1382633 - /lucene/dev/trunk/lucene/spatial/src/java/overview.html

I figured that is why the decision was made. I think exceptions can be made as long as one understands the down side. An alternative solution to this decision is to simply make sure the URL doesn't 404. ~ David On Sep 10, 2012, at 7:08 AM, Michael McCandless wrote: > On Sun, Sep 9, 2012 at 1

Re: RecursivePrefixTreeFieldType class not found

Hi Dan, That page is the in-progress documentation for this: https://issues.apache.org/jira/browse/SOLR-3304 which hasn't been committed and so it requires you check out Lucene/Solr and apply the patch. The class reference will be solr.SpatialRecursivePrefixTreeFieldType. I updated the wiki.

SolrTestCaseJ4: Can't avoid "collection1" convention

I've got some code that extends Solr and I use the Solr test framework for my tests. I upgraded from Solr 4 alpha to Solr 4 beta today, and it appears I am forced to put my test solr home directory in solr/collection1 rather than just plain solr/ (relative to my test classpath). I looked thro

ResourceLoaderAware inform() before or after init()

Hi folks. I am wondering what the expected initialization sequence of the analysis factories are with respect to init() and ResourceLoaderAware.inform(). At least judging from some tests, it seems that inform() is called afterwards. I was expecting the other way around, so that init() can do

Move ValueSourceFilter to query module?

In the spatial utils package I've got a ValueSourceFilter which is a Filter based on a ValueSource with a minimum and maximum range. It does what you'd think it does. This seems like something useful in the query module in the org.apache.lucene.queries.function package. Any opinions? Here is

FST bug?

I am building an FST. Here is an excerpt from my code; //build the FST from the workingSet Builder builder = new Builder(FST.INPUT_TYPE.BYTE4, outputs); IntsRef sortedKeys[] = workingSet.keySet().toArray(new IntsRef[workingSet.size()]); Arrays.sort(sortedKeys); int maxPhrase

Re: SynonymFilter, FST, and Aho-Corasick algorithm

Thanks for your explanation, I already had a very rough idea of the approach. Can Aho-Corasick be implemented with Lucene's FST? Again, the SynonymFilterFactory said this RE Aho-Corasick: // This really amounts to adding a .* // closure to the FST and then determinizing it. You didn't mention

Re: SynonymFilter, FST, and Aho-Corasick algorithm

s I see it. ~ David On Jul 12, 2012 5:09 PM, "Smiley, David W." mailto:dsmi...@mitre.org>> wrote: Hello. I'm embarking on developing code similar to the SynonymFilter but which merely needs to record out of band to the analysis where there is matching text in the input

SynonymFilter, FST, and Aho-Corasick algorithm

Hello. I'm embarking on developing code similar to the SynonymFilter but which merely needs to record out of band to the analysis where there is matching text in the input tokens to the corpus in the FST. I'm calling this a "keyword tagger" in which I shove text through it and when it's done

Re: IRC chat tonight on lucene spatial?

I meant 3:30am UTC Monday, not Sunday. The UTC/ET thing confused me. On Jun 29, 2012, at 2:03 PM, Smiley, David W. wrote: > That was a bust :-( > > Instead, I propose 3:30am UTC (same time) Sunday night. I'll use UTC times > because it is more universal for us as

Re: IRC chat tonight on lucene spatial?

That was a bust :-( Instead, I propose 3:30am UTC (same time) Sunday night. I'll use UTC times because it is more universal for us as we span the globe. ~ David On Jun 28, 2012, at 4:24 PM, Smiley, David W. wrote: > Chris, Ryan, > I propose, if possible, that we chat on irc

Re: Use of @Slow annotation on tests

+1 Love it On Jun 29, 2012, at 4:42 AM, Dawid Weiss wrote: > Hi. I would like to change the use of @Slow. Currently only this test: > > Test2BTerms#test2BTerms > > is annotated with this annotation. I don't know how slow it really is, > but I would like to: > > * change this particular test to

IRC chat tonight on lucene spatial?

Chris, Ryan, I propose, if possible, that we chat on irc at #lucene-dev at ~11:30pm ish ET (7 hours from now). I'd like to discuss the core elements of the Spatial Strategy API, namely makeQuery, makeFilter, makeValueSource, and SpatialOperation. I plan to stay logged in tonight to #lu

Re: Welcome Adrien Grand as a new Lucene/Solr committer

Welcome Adrien! ~ David On Jun 7, 2012, at 2:11 PM, Michael McCandless wrote: > I'm pleased to announce that Adrien Grand has joined our ranks as a > committer. > > He has been contributing various patches to Lucene/Solr, recently to > Lucene's packed ints implementation, giving a nice performan

Re: CHECKSUM FAILED for commons-fileupload-1.2.1.jar

d can be fixed by clearing the Ivy cache, triggering a re-download. (To automate this, we could wrap the ant task: <http://ant.apache.org/ivy/history/2.2.0/use/cleancache.html>.) Steve From: Smiley, David W. [mailto:dsmi...@mitre.org] Sent: Friday, May 18, 2012 11:49 AM To: dev@lucene

CHECKSUM FAILED for commons-fileupload-1.2.1.jar

I'm trying to build Lucene/Solr today, svn updated, then went to do a compile and I got this: CHECKSUM FAILED for /SmileyDev/Search/lucene-solr_svn/solr/lib/commons-fileupload-1.2.1.jar (expected: "384faa82e193d4e4b0546059ca09572654bc3970" was: "fd968960d004ba8863a2e7b9c88f260aa588c22d") I th

Re: Ant version for building Solr

On Apr 23, 2012, at 11:19 AM, Robert Muir wrote: > On Mon, Apr 23, 2012 at 10:37 AM, Smiley, David W. wrote: >> I understand your point Rob. But given your point of view, wouldn't it be >> sufficient for the README to simply say "download Ant 1.7 and…" without

Re: Ant version for building Solr

I understand your point Rob. But given your point of view, wouldn't it be sufficient for the README to simply say "download Ant 1.7 and…" without explicitly telling the user *not* to use Ant 1.8, which is suggestive of a particular problem with the newer version? You didn't tell them *not* to

Re: VOTE: Lucene/Solr 3.6

On Apr 5, 2012, at 5:22 PM, Robert Muir wrote: > On Thu, Apr 5, 2012 at 5:03 PM, Smiley, David W. wrote: >> There is a lingering discussion that comes to mind here: >> https://issues.apache.org/jira/browse/SOLR-2724 >> Title: Deprecate defaultSearchField and defau

Re: VOTE: Lucene/Solr 3.6

There is a lingering discussion that comes to mind here: https://issues.apache.org/jira/browse/SOLR-2724 Title: Deprecate defaultSearchField and defaultOperator defined in schema.xml Essentially I committed this to 3x and trunk, trunk was subsequently reverted due to something else entirely, b

Re: Welcome David Smiley

Thanks Mikhail. Here's why: https://issues.apache.org/jira/browse/SOLR-2155?focusedCommentId=13209613&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13209613 ~ David On Feb 10, 2012, at 1:20 PM, Mikhail Khludnev [via Lucene] wrote: I'm joining to all congratulatio

LUCENE-3795 Replace spatial contrib module with LSP's spatial-lucene module

I made a major proposal to Lucene to replace its spatial contrib module with one in LSP -- a project that Chris Male, Ryan McKinley and I have been working on. In case you guys missed the JIRA issue, here it is: https://issues.apache.org/jira/browse/LUCENE-3795 I ask for any input, assuming you

Re: Add "hint" to Solr QParser that it is a filter query

On Nov 7, 2011, at 3:41 PM, Chris Hostetter wrote: > > : I would love to know when it is okay to return a ConstantScoreQuery > : wrapping my Filter so that I needn't bother with my ValueSource. In my > : opinion, FieldType should have a getFieldFilter() method similar to > : getFieldQuery().

Add "hint" to Solr QParser that it is a filter query

I am implementing a custom Solr FieldType for Solr trunk. One method I override is: Query getFieldQuery(QParser parser, SchemaField field, String externalVal) My Query implementation can be vastly more efficient if the scores aren't needed vs. when they are needed. My code constructing this

Re: FindBugs & PMD ?

read your thoughts on custom PMD rules. I think that's a fantastic idea. I'm not sure if these rules should be PMD rules or FindBugs rules, but we can cross that bridge when we come to it. AFAIK, FindBugs is way more popular so I would favor that. ~ David On Jul 8, 2011, at 3:17

Re: FindBugs & PMD ?

For build integration, I'd like to do this on the maven side. It's easier there, and it should not matter that it's not the official build since it only needs to be run by Jenkins which is already running the maven build any way. ~ David On Jul 8, 2011, at 10:08 AM, Smiley,

Re: FindBugs & PMD ?

s.jar? Or are all of them not available to runtime? > > Uwe > > - > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de > >> -Original Message- >> From: Smiley, David W. [mailto:dsmi...@mitre.org]

Re: FindBugs & PMD ?

Rob, there is an ASL 2.0 licensed implementation here: https://github.com/stephenc/findbugs-annotations ~ David On Jul 8, 2011, at 10:12 AM, Robert Muir wrote: > On Fri, Jul 8, 2011 at 10:08 AM, Smiley, David W. wrote: >> Developers, >> Any thoughts on using FindBugs & PMD

FindBugs & PMD ?

Developers, Any thoughts on using FindBugs & PMD to catch more bugs in Lucene/Solr? Jenkins could be configured to run FindBugs & PMD analysis nightly. It would have helped find this: (LUCENE-3294) Some code still compares string equality instead using equals I am aware there are a

Please commit SOLR-2616 Include jdk14 logging configuration file

Please review/commit: https://issues.apache.org/jira/browse/SOLR-2616"Include jdk14 logging configuration file" ~ David - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@luc

Re: Getting patches (with tests!) committed

with "Commit this, pretty please?" messages. Or not and they will say in the JIRA graveyard. > But I've just assigned it to myself, I'll see if I can get it > committed, I'm new enough at the process that I need the practice I noticed, thanks. > Best > Eri

Getting patches (with tests!) committed

How do committers recommend that patch contributors (like me) get their patches committed? At the moment I'm thinking of this one: https://issues.apache.org/jira/browse/SOLR-2535 This is a regression bug. I found the bug, I added a patch which fixes the bug and tested that it was fixed. The tes

Re: Improvements to the maven build

On May 4, 2011, at 7:14 PM, Ryan McKinley wrote: > As a rule, everything should go through JIRA on its way to svn -- this > is important so that we have somewhere to point for why we did things. > Even small things. Even "small" things?! It would be a royal pain in the ass to submit an issue fo

Re: Improvements to the maven build

On May 4, 2011, at 6:43 PM, Steven A Rowe wrote: >> >> 6. The ant solr build puts all its final artifacts into the solr/dist >> directory, the maven build does not--it leaves all of them in their build >> directory. Not a big deal but maybe there's a way to have the output file >> go someplace el

Re: jira issues falling off the radar -- "Next" JIRA version

Marge away ;-) On May 5, 2011, at 3:24 PM, Chris Hostetter wrote: > I suggest we marge "Next" into "3.2" ... > > http://confluence.atlassian.com/display/JIRA/Managing+Versions#ManagingVersions-Mergingmultipleversions > > > ...objections?

Improvements to the maven build

Steve Row, I thought I'd put together a list of interesting differences between the ant build output and the maven build output. Before each build I did a full clean and then after the build I saved a file listing to a text file so that I could diff it. I'm using svn revision 1087373 (March 3

Re: jira issues falling off the radar -- "Next" JIRA version

On May 2, 2011, at 7:54 PM, Chris Hostetter wrote: > We should definitely kill of "Next" ... i would suggest just removing it, > and not bulk applying a new version (there is no requirement that issues > have a version) Chris, in JIRA, "Next" has this description: > Placeholder for commiters

Re: PipeLine for Solr

Great discussion here; although I do believe it belongs on the Solr user list because we're not talking about development on Solr. I'm very tempted to cross-post but I believe that's discouraged so I won't. > Still wondering where the Solr Community will bring this in the future? I strongly be

Re: [POLL] JTS compile/test dependency

On Apr 6, 2011, at 2:12 PM, Ryan McKinley wrote: > [ ] OK with JTS compile dependency. Spatial support should be a module > [X] OK with JTS, but think this spatial stuff should happen elsewhere > [ ] Please, no LGPL dependencies in lucene build ~ David Smiley Author: http://www.packtpub.com/solr

Re: Lucene Spatial Future

On Apr 6, 2011, at 2:08 PM, Grant Ingersoll wrote: >> with its replacement being an externally hosted ASL-licened module expressly >> designed to work with Lucene/Solr 4.0 and beyond (temporarily known as >> lucene-spatial-playground). What would stay is the _basic_ spatial support >> that got

Re: Lucene Spatial Future

On Apr 6, 2011, at 11:38 AM, Grant Ingersoll wrote: > Until there is a specific patch that brings in and shows how JTS would be > incorporated (via reflection and as a totally optional piece, presumably, per > the ASF LGPL guidelines), there really isn't anything to vote on. I think what is bei

RE: Wiki docs about compression

Yes, you're right Eric. The feature was removed in Solr 1.4.1 much to my chagrin. On my todo list in the next couple months or so, I intend to bring it back -- at least for 4.0 ~ David From: Eric Pugh [ep...@opensourceconnections.com] Sent: Wednesday, Ap

RE: Lucene Spatial Future

day, April 05, 2011 11:23 AM To: dev@lucene.apache.org Cc: Smiley, David W. Subject: Re: Lucene Spatial Future Forgive my ignorance, but: are there any technical reasons for spatial work to be "in core"? Or can all the spatial algos be "safely" (ie, won't lose much per

RE: Lucene Spatial Future

> Alternatively, has anyone simply asked JTS if they would dual license or > something like that? I'm happy to do that, but let's coordinate so that we > aren't all bombarding the guy. I did already. Martin didn't respond but someone else did and the outlook is highly unlikely (see Ryan's poi

Re: Lucene Spatial Future

On Apr 3, 2011, at 3:50 PM, Ryan McKinley wrote: > In the days of sub-projects, I would have proposed that option, but > now I see two options: > > A. Work on spatial lucene outside of apache -- perhaps osgeo or even > just github. (would need a different name) > B. Allow JTS compile-time depen

RE: 3.1.0 Proposed Release Announcement(s)

Grant, In Solr, you missed the substantial feature of numeric range faceting (supports dates; the previous date faceting is deprecated.). Perhaps you might also point out that this still does *not* support distributed search ;-P Also, I would include a note at the lead-in of the Solr section o

RE: [jira] [Commented] (SOLR-2155) Geospatial search using geohash prefixes

Just a small piece of feedback on your note Bill. I don't need more help in knowing the best way to support multi-value sort. I've figured out an approach I feel confident in (and it's 1/3 coded)... were it not for my new baby (and the 2nd edition of my book for sure!) you'd be using it right

Re: custom ValueSource for decoding geohash into lat & lon

On Mar 10, 2011, at 6:21 PM, William Bell wrote: > 1. ValueSources does not support MultiValue fields. I think the problem isn't ValueSources, it's the FieldCache. The FieldCache is fundamentally very limited to one indexed primitive value per document. I took a look at UninvertedField but th

Re: custom ValueSource for decoding geohash into lat & lon

On Mar 10, 2011, at 6:21 PM, William Bell wrote: > OK. But I am concerned that you are trying to bite off more than can > be done easily. The sample call is: > > http://localhost:8983/solr/select?q=*:*&fq={!geofilt}&sfieldmulti=storemv&pt=43.17614,-90.57341&d=100&sfield=store&sort=geomultidist%2

custom ValueSource for decoding geohash into lat & lon

I'm looking for validation of my approach to geospatial sorting from committers. I'm starting work on implementing sorting for my geohash based filter code in https://issues.apache.org/jira/browse/SOLR-2155 The existing GeohashHaversineFunction uses ValueSources based on the the natural string

Re: [VOTE] Lucene and Solr 3.1 release candidate

So https://issues.apache.org/jira/browse/SOLR-2405 didn't make it in yesterday (apparently it didn't)? :-( Darn... maybe I shouldn't have waited for a committer to agree with the issue. I would have had it in Saturday. ~ David Smiley On Mar 7, 2011, at 1:32 AM, Robert Muir wrote: > Hi all, >

RE: Why does DIH jar end up in Solr war?

it really work being loaded, and friends, by SolrResourceLoader)? Erik On Feb 16, 2011, at 00:57 , Smiley, David W. wrote: > I noticed that the DIH .jar file ends up in the .war file. It ends up this > way because the DIH's build.xml copies it into a place so that it ultimately &g

Why does DIH jar end up in Solr war?

I noticed that the DIH .jar file ends up in the .war file. It ends up this way because the DIH's build.xml copies it into a place so that it ultimately winds up there. This seems like an odd thing because no other contrib module gets this special treatment. I noticed that the dataimport.jsp h

RE: Please mark distributed date faceting for 3.1

ent: Tuesday, February 15, 2011 10:24 AM To: dev@lucene.apache.org Subject: Re: Please mark distributed date faceting for 3.1 On Tue, Feb 15, 2011 at 10:10 AM, Smiley, David W. wrote: > Distributed date faceting now has a patch and is tested: > > https://issues.apache.org/jira/browse/SO

RE: Any contribs available for Range field type?

"solr-dev" is the old list; it's now just "dev". The old one forwards to the new list though. ~ David From: mike anderson [mailto:saidthero...@gmail.com] Sent: Tuesday, February 15, 2011 10:51 AM To: solr-...@lucene.apache.org Cc: ken.fos...@realestate.com Subject: Fwd: Any contribs available fo

Please mark distributed date faceting for 3.1

Distributed date faceting now has a patch and is tested: https://issues.apache.org/jira/browse/SOLR-1709 I'm posting to the dev list because I want a committer to mark this for 3.1. I don't want to assume any of you guys see the comment activity. ~ David

Re: Use of MultiFields.getFields() bad practice?

On Jan 5, 2011, at 1:35 PM, Uwe Schindler wrote: > BUT: > > I am just upset about such code: > > final DocIdSet dis = filter.getDocIdSet(reader); > if (dis == null) >return null; > final DocIdSetIterator disi = dis.iterator(); > if (disi == null) >return null;

Use of MultiFields.getFields() bad practice?

I'm looking through the trunk code on various implementations of Filter.getDocIdSet(IndexReader). It is often needed to get an instance of Terms and then do other work from there. Looking at MultiTermQueryWrapperFilter, the first set of lines to do this is: public DocIdSet getDocIdSet(Index

Re: Geospatial search in Lucene/Solr

ec 28, 2010, at 11:18 AM, Robert Muir wrote: > On Tue, Dec 28, 2010 at 10:47 AM, Smiley, David W. wrote: >> Presently, I’m working on Lucene’s benchmark contrib module to evaluate the >> performance of SOLR-2155 compared to the LatLon type (i.e. a pair of lat-lon >> range que

Re: Geospatial search in Lucene/Solr

(I was emailing Grant RE geospatial search and it occurred to me I should be doing this on the Lucene dev list so I've taken it there) On Dec 28, 2010, at 8:31 AM, Grant Ingersoll wrote: On Dec 27, 2010, at 11:52 PM, Smiley, David W. wrote: Hi Grant. I saw your latest blog post at

RE: discussion about release frequency.

It's good to see what appears to be a maven-positive resolution to this thread. I've gotten to this thread late, but FWIW, I've agreed with basically everything Ryan has said, as I am a maven user too. What would be *really cool* is Hudson automatically uploading the artifacts of each build to

Distributed search forces standard request handler?

I registered a request handler named after my application. Aside from various defaults that I configured, I also registered some components I've written. When I tried to do a distributed search, I noticed that the secondary Solr requests internal to the workings of the distributed search were g

RE: Repeat to the right list: Solr spewage and possible re-entrancy problem?

Maybe its related to this: https://issues.apache.org/jira/browse/SOLR-1941 Simply switch to Jetty's BoundedThreadPool or try Tomcat. ~ David Smiley Author: https://www.packtpub.com/solr-1-4-enterprise-search-server/book -Original Message- From: karl.wri...@nokia.com [mailto:karl.wri...@