Re: Sorry for JIRA spam

[David Smiley (@MITRE.org)]

What I mean is that when you click the “Release” menu choice next to the 
version, JIRA optionally asks you if it should bump the fix versions (I forget 
the precise language).  It didn’t say that in doing so it would send a ton of 
email, and it didn’t give an option to suppress email.  Separately from this, 
the release instructions we have in our wiki describe how to advance the 
fix-versions in a way that suppresses email.  But if beforehand you let JIRA do 
it for you with just one-click as part of releasing the version, then it’ll 
send out the mass email.
~ David

From: "Mark Miller-3 [via Lucene]" 
mailto:ml-node+s472066n4124847...@n3.nabble.com>>
Date: Monday, March 17, 2014 at 11:41 AM
To: "Smiley, David W." mailto:dsmi...@mitre.org>>
Subject: Re: Sorry for JIRA spam

I don’t think it’s bad to have JIRA bump the fix version at all - you just want 
to supress an individual email for each change if its going to be that many.

--
Mark Miller
about.me/markrmiller


On March 16, 2014 at 9:45:42 AM, David Smiley (@MITRE.org) ([hidden 
email]) wrote:

Sorry for all the email spam last night, folks.

I "Released" Lucene & Solr 4.7 in JIRA last night. I updated the
instructions here
https://wiki.apache.org/lucene-java/ReleaseTodo#Update_JIRA to explicitly
indicate *not* to have JIRA bump the Fix-version values.

~ David



-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Sorry-for-JIRA-spam-tp4124545.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: [hidden 
email]
For additional commands, e-mail: [hidden 
email]




If you reply to this email, your message will be added to the discussion below:
http://lucene.472066.n3.nabble.com/Sorry-for-JIRA-spam-tp4124545p4124847.html
To unsubscribe from Sorry for JIRA spam, click 
here<http://lucene.472066.n3.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4124545&code=RFNNSUxFWUBtaXRyZS5vcmd8NDEyNDU0NXwxMDE2NDI2OTUw>.
NAML<http://lucene.472066.n3.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>




-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Sorry-for-JIRA-spam-tp4124545p4124848.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

Re: Use of fix version

[David Smiley (@MITRE.org)]

Jack Krupansky-2 wrote
> And maybe there needs to be special formatting to highlight the importance 
> of "Uncheck the box that says "send an email for these changes"."",
> although 
> the omission of that step did highlight the main issue I mentioned.

My error was not neglecting to see that, it was letting JIRA bump the
fix-for versions as part of choosing "Release" menu next to the version in
the version screen.  So I added explicit instructions on the choice on the
wiki.

Sorry again.

To your larger point of fix-for versions... we can't stop users using them
how we might want them to be used, so there's little benefit in trying to
have it reflect some particular meaning (i.e. it really really will be
likely to be done by fix-for version).

~ David




-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Use-of-fix-version-tp4124560p4124561.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Sorry for JIRA spam

[David Smiley (@MITRE.org)]

Sorry for all the email spam last night, folks.

I "Released" Lucene & Solr 4.7 in JIRA last night.  I updated the
instructions here
https://wiki.apache.org/lucene-java/ReleaseTodo#Update_JIRA to explicitly
indicate *not* to have JIRA bump the Fix-version values.

~ David



-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Sorry-for-JIRA-spam-tp4124545.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Any reason Solr Jira still lists 4.7 as unreleased?

[David Smiley (@MITRE.org)]

I fixed this last night & this morning.


Alexandre Rafalovitch wrote
> I was doing some searching on issues and noticed 4.7 is listed in
> "Unreleased versions". Also, I have a couple of open issues that
> (possibly due to my mistake) are marked as open but target at 4.7.
> 
> Was not sure if this is a process that normally lags the actual
> version release or something to notify. So, I am notifying.
> 
> Regards,
>Alex.
> Personal website: http://www.outerthoughts.com/
> LinkedIn: http://www.linkedin.com/in/alexandrerafalovitch
> - Time is the quality of nature that keeps events from happening all
> at once. Lately, it doesn't seem to be working.  (Anonymous  - via GTD
> book)
> 
> -
> To unsubscribe, e-mail: 

> dev-unsubscribe@.apache

> For additional commands, e-mail: 

> dev-help@.apache





-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Any-reason-Solr-Jira-still-lists-4-7-as-unreleased-tp4123605p4124544.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [ANNOUNCE] Apache Lucene 4.7.0 released.

[David Smiley (@MITRE.org)]

Woohoo!  And thanks for all your hard work as R.M., Simon.



-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/ANNOUNCE-Apache-Lucene-4-7-0-released-tp4119813p4119840.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Solr Reference Guide pages; turn off comments?

[David Smiley (@MITRE.org)]

+1 to both ideas:  delete at the time we address a comment (rendering the 
comment obsolete) and/or do so at release time if we neglected to delete a 
comment earlier.  It’s a low-priority thing any way.

But what about comments that don’t lead to an edit to the page?  I’ve asked 
about the utility of Solr’s new HDFS related support some months ago on a page 
and I don’t think it resulted in a page change.  So I think if we have 
questions about the capabilities, the page comments may not be the right place 
for them.

This page has a lot of comments (including mine):
https://cwiki.apache.org/confluence/display/solr/Running+Solr+on+HDFS

~ David

From: "Shawn Heisey-4 [via Lucene]" 
mailto:ml-node+s472066n4119130...@n3.nabble.com>>
Date: Sunday, February 23, 2014 at 1:19 PM
To: "Smiley, David W." mailto:dsmi...@mitre.org>>
Subject: Re: Solr Reference Guide pages; turn off comments?

On 2/23/2014 10:49 AM, Mark Miller wrote:
> On Feb 23, 2014, at 12:47 PM, Steve Rowe <[hidden 
> email]> wrote:
>
>> Maybe delete comments that have been addressed after each release?
>
> +1 - a time delay seems like a good idea. Though the burden of work may make 
> the system less effective.

I have no idea what the paradigm I'm thinking of is called in
programming, but it's very common in website design, and is inherent in
the implementation of anacron.  Describing it is harder than
understanding it. :)

http://en.wikipedia.org/wiki/Anacron

Rather than add a potentially unbearable task to the release process, we
can review comments anytime a page requires a change.  Anything that is
no longer applicable can be deleted at that time.

A good rule of thumb might be that we only keep comments that haven't
been resolved or are resolved by the current minor release or its point
releases.  If it was resolved by the previous minor release or anything
older, we delete them.  There will be exceptions, but hopefully common
sense can be the deciding factor.

Thanks,
Shawn




-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Solr-Reference-Guide-pages-turn-off-comments-tp4119062p4119275.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

Solr Reference Guide pages; turn off comments?

[David Smiley (@MITRE.org)]

I was just thinking about the comments feature of the Solr Reference Guide
(e.g. Confluence).  On one hand it's a nice feature that also allows
non-committers to be involved.  But, over time, couldn't it easily get out
of hand (as-implemented)?  That is... as a series of ever-growing comments
that make the page longer and longer, it seems it *could* become a bad thing
over time.  It isn't a problem now on the pages I've seen.  It's easy to
falsely make a like-kind comparison to JIRA issues but there is a big
difference because JIRA issues become closed!  A reference guide page will
likely live forever.  Perhaps my concern could be addressed in a
presentational way, like if you consider that MediaWiki has a separate
screen/page for this kind of thing; and as such I think is more manageable
then growing the original page forever.  I checked for a Confluence plugin
for that but turned up nothing obvious in Atlassian's plugin marketplace.

So I may have commented on a page in the past but I have no intention in
adding any more.  If I have a comment; I'll make it on the dev list.

~ David



-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Solr-Reference-Guide-pages-turn-off-comments-tp4119062.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: DISCUSS: Go "all in" on github integration

[David Smiley (@MITRE.org)]

Nice!
And I see the infra ticket was "fixed" today.
Hopefully it will encourage more contributions.  If someone can show an
example of this in action (not necessarily Lucene/Solr) it'd be nice to see.

Unfortunately, there's still a huge gap between an actual bona-fide GitHub
run project, and what we have with respect to us committers.  Although
perhaps for a contributing user there is little difference now, and that's
fantastic since that's part of the point of being on GitHub -- ease of
contribution.

~ David


Chris Hostetter-3 wrote
> As some folks may know, apache infra has been making lots of improvements 
> to how the users of the github mirrors of ASF projects can interact with 
> the regular apache dev cycle.
> 
> A while back, some of these features were enabled for the Lucene/Solr code 
> base, and we have already had a few contributions submitted as Github Pull 
> Requests that were then committed.
> 
> Infra has recently announced more autoamted integration between github 
> concepts and regular Apache work flow on the mailing lists & Jira -- on a 
> per-project Opt-In basis...
> 
> https://blogs.apache.org/infra/entry/improved_integration_between_apache_and
> 
> ...It's not entirely clear to me how fine grained the enable/disable 
> controls are for some of these features -- wether we already have all of 
> these features enabled based on our past infra requests, or if we need to 
> "opt-in again" to the new ones before we'll see any changes ... but my 
> suggestion is that we file a Jira with infra that says something to the 
> effect of...
> 
>   "The Lucene PMC wishs to opt-in on any and all github related project
>linkages that are available that we may not already be opted-in to."
> 
> 
> Any objections?
> 
> 
> -Hoss
> http://www.lucidworks.com/
> 
> -
> To unsubscribe, e-mail: 

> dev-unsubscribe@.apache

> For additional commands, e-mail: 

> dev-help@.apache





-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/DISCUSS-Go-all-in-on-github-integration-tp4117011p4117314.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Welcome Benson Margulies as Lucene/Solr committer!

[David Smiley (@MITRE.org)]

Awesome to have another committer, and in my neck of the woods too. Welcome!




-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Welcome-Benson-Margulies-as-Lucene-Solr-committer-tp4113502p4115165.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_60-ea-b03) - Build # 9227 - Still Failing!

[David Smiley (@MITRE.org)]

Fixed.  (Yes I do know about "ant precommit"... but long story never mind why
these problems happenned.)



-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/JENKINS-Lucene-Solr-trunk-Linux-32bit-jdk1-7-0-51-Build-9224-Failure-tp4113340p4113397.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_51) - Build # 9224 - Failure!

[David Smiley (@MITRE.org)]

Whoops; I thought I got the sha1's correctly; I'll try again.



-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/JENKINS-Lucene-Solr-trunk-Linux-32bit-jdk1-7-0-51-Build-9224-Failure-tp4113340p4113363.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Welcome Areek Zillur as Lucene/Solr committer!

[David Smiley (@MITRE.org)]

Awesome; glad to have you Areek!
~ David


Areek Zillur wrote
> Thanks Robert! I am very pleased to be a committer to Lucene/Solr!
> 
> I am originally from Dhaka, Bangladesh. I am currently a 4th year Computer
> Engineering
> student at University of Waterloo in Canada. I was fortunate enough to
> have
> multiple internships
> all over North America through the university's co-op program.
> I was first introduced to Lucene/Solr in one of my work-terms at A9 and
> loved it.
> 
> I really enjoy the open-source development and the friendliness of the
> community
> behind Lucene/Solr.
> In my free time, I enjoy working on working on my  recreational
> algorithmic
> trading system and learning
> new programming languages.
> 
> I hope to continue to work on Lucene/Solr and learn a lot more from the
> community!
> 
> Thanks,
> 
> Areek Zillur
> 
> 
> On Tue, Jan 21, 2014 at 11:41 AM, Yonik Seeley <

> yonik@

> >wrote:
> 
>> Welcome Areek!
>>
>> -Yonik
>> http://heliosearch.com -- making solr shine
>>
>> On Tue, Jan 21, 2014 at 2:26 PM, Robert Muir <

> rcmuir@

> > wrote:
>> > I'm pleased to announce that Areek Zillur has accepted to join our
>> ranks
>> as
>> > a committer.
>> >
>> > Areek has been improving suggester support in Lucene and Solr,
>> including
>> a
>> > revamped Solr component slated for the 4.7 release. [1]
>> >
>> > Areek, it is tradition that you introduce yourself with a brief bio.
>> >
>> > Once your account is setup, you should then be able to add yourself to
>> the
>> > who we are page on the website as well.
>> >
>> > Congratulations and welcome!
>> >
>> > [1] https://issues.apache.org/jira/browse/SOLR-5378
>> >
>>
>> -
>> To unsubscribe, e-mail: 

> dev-unsubscribe@.apache

>> For additional commands, e-mail: 

> dev-help@.apache

>>
>>





-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Welcome-Areek-Zillur-as-Lucene-Solr-committer-tp4112516p4113279.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: The Old Git Discussion

[David Smiley (@MITRE.org)]

+1, Mark.

Git isn't perfect; I sympathize with the annoyances pointed out by Rob et.
all.  But I think we would be better off for it -- a net win considering the
upsides.  In the end I'd love to track changes via branches (which includes
forks people make to add changes), not with attaching patch files to an
issue tracker.  The way we do things here sucks for collaboration and it's a
higher bar for people to get involved than it can and should be.

~ David


Mark Miller-3 wrote
> I don’t really buy the fad argument, but as I’ve said, I’m willing to wait
> a little longer for others to catch on. I try and follow the stats and
> reports and articles on this pretty closely.
> 
> As I mentioned early in the thread, by all appearances, the shift from SVN
> to GIT looks much like the shift from CVS to SVN. This was not a fad
> change, nor is the next mass movement likely to be.
> 
> Just like no one starts a project on CVS anymore, we are almost already to
> the point where new projects start exclusive on GIT - especially open
> source.
> 
> I’m happy to sit back and watch the trend continue though. The number of
> GIT users in the committee and among the committers only grows every time
> the discussion comes up.
> 
> If this was 2009, 2010, 2011 … who knows, perhaps I would buy some fad
> argument. But it just doesn’t jive in 2014.
> 
> - Mark





-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/The-Old-Git-Discussion-tp4109193p4110109.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Is there a really performant way to store a full 32-bit int in doc values?

[David Smiley (@MITRE.org)]

Nice investigation Mike!  Your observation about it doing multiple block 
decodes is one reason why I chose BinaryDocValues in SOLR-5170 to use one 
byte[] for a pair of numbers.  In Karl's last email he remarked this was still 
only 20% faster than looking up a pair of NumericDocValues; I suspect moving to 
Memory DVFormat will help more.

~ David

From: "Michael McCandless-2 [via Lucene]" 
mailto:ml-node+s472066n4094143...@n3.nabble.com>>
Date: Tuesday, October 8, 2013 2:31 PM
To: "Smiley, David W." mailto:dsmi...@mitre.org>>
Subject: Re: FW: Is there a really performant way to store a full 32-bit int in 
doc values?

…

So, ~46% faster: ~405 msec vs 592 msec

You should be able to do even better with a custom DVFormat, because
even forcing 32 bits per value, it's still doing block decode, so
every get must first find the block then lookup value within the block.

Mike McCandless

http://blog.mikemccandless.com






-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Re-Is-there-a-really-performant-way-to-store-a-full-32-bit-int-in-doc-values-tp4094150.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

Re: FW: Is there a really performant way to store a full 32-bit int in doc values?

[David Smiley (@MITRE.org)]

Hi Karl!

I suggest that you put the point data you need in BinaryDocValues.  That is
both the x & y into the same byte[] chunk.  I've done this for a Solr
integration in https://issues.apache.org/jira/browse/SOLR-5170

~ David


karl.wright-2 wrote
> Hi All (and especially Robert),
> 
> Lucene NumericDocValues seems to operate slower than we would expect.  In
> our application, we're using it for storing coordinate values, which we
> retrieve to compute a distance.  While doing timings trying to determine
> the impact of including a sqrt in the calculation, we noted that the
> lucene overhead itself overwhelmed pretty much anything we did in the
> ValueSource.
> 
> One of our engineers did performance testing (code attached, hope it gets
> through), which shows what we are talking about.   Please see the thread
> below.  The question is: why is lucene 2.5x slower than a direct buffer
> access for this case?  And is there anything we can do in the Lucene
> paradigm to get our performance back closer to the direct buffer case?
> 
> Karl
> 
> -Original Message-
> From: Ziech Christian (HERE/Berlin) 
> Sent: Tuesday, October 08, 2013 9:08 AM
> To: Wright Karl (HERE/Cambridge)
> Subject: AW: Is there a really performant way to store a full 32-bit int
> in doc values?
> 
> Hi,
> 
> I have tested now the approach with usind the NumericDocValues directly
> and it indeed helps about 20% compared to the original Lucene numbers -
> Lucene is still 2,5x slower than using a DirectBuffer alone but it helps.
> The funny thing is really that with lucene using the SquareRoot is almost
> meaningless which can be explained well by the CPU calculating the
> SquareRoot while other things are computated and since it doesn't need the
> result for a while in my micro-Benchmark it can happily do other things in
> the meantime. Since we also have a lot of other query aspects we'd get
> that gain either way I assume so calculating about 30-50ms for the square
> root for the scoring 25M documents should be about accurate. So what is
> lucene doing that causes it to be 3 times slower than the naive approach.
> And why is that impact compared to the one of a simple square root
> (slowing down things by ~20% when assuming the 30ms with more complex
> actions) so big? I mean 20% vs 200% is a magnitude!
> As a side note: Storing the values as a int when using a DirectBuffer
> doesn't seem helpful - I assume because we have to cast the in to float
> either way later.
> 
> BR
>   Christian
> 
> PS: The new numbers are:
> Scoring 2500 documents with direct float buffers (without square root)
> took 190 
> 
> Scoring 2500 documents with direct float buffers (without square root)
> took 171 
> 
> Scoring 2500 documents with direct float buffers (without square root)
> took 172 
> 
> Scoring 2500 documents with direct float buffers (and a square root)
> took 281 
> 
> Scoring 2500 documents with direct float buffers (and a square root)
> took 280 
> 
> Scoring 2500 documents with direct float buffers (and a square root)
> took 266 
> 
> Scoring 2500 documents with a lucene float value source (without
> square root) took 1045 
> 
> Scoring 2500 documents with a lucene float value source (without
> square root) took 625 
> 
> Scoring 2500 documents with a lucene float value source (without
> square root) took 630 
> 
> Scoring 2500 documents with a lucene float value source (and a square
> root) took 661 
> 
> Scoring 2500 documents with a lucene float value source (and a square
> root) took 670 
> 
> Scoring 2500 documents with a lucene float value source (and a square
> root) took 665 
> 
> Scoring 2500 documents with direct int buffers (without square root)
> took 218 
> 
> Scoring 2500 documents with direct int buffers (without square root)
> took 219 
> 
> Scoring 2500 documents with direct int buffers (without square root)
> took 204 
> 
> Scoring 2500 documents with a lucene numeric values (without square
> root) source took 1123 
> 
> Scoring 2500 documents with a lucene numeric values (without square
> root) source took 500 
> 
> Scoring 2500 documents with a lucene numeric values (without square
> root) source took 499 
> 
> Scoring 2500 documents with a lucene numeric values (and a square
> root) source took 531 
> 
> Scoring 2500 documents with a lucene numeric values (and a square
> root) source took 531 
> 
> Scoring 2500 documents with a lucene numeric values (and a square
> root) source took 535
> 
> 
> 
> Von: Wright Karl (HERE/Cambridge)
> Gesendet: Montag, 7. Oktober 2013 09:22
> An: Ziech Christian (HERE/Berlin)
> Betreff: FW: Is there a really performant way to store a full 32-bit int
> in doc values?
> 
> -Original Message-
> From: ext Michael McCandless [mailto:

> lucene@

> ]
> Sent: Monday, October 07, 2013 8:28 AM
> To: Wright Karl (HERE/Cambridge)
> Subject: Re: Is there a really 

Re: Welcome Joel Bernstein

[David Smiley (@MITRE.org)]

Welcome to the team Joel!



-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Welcome-Joel-Bernstein-tp4093247p4093417.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [jira] [Updated] (SOLR-2345) Extend geodist() to support MultiValued lat long field

[David Smiley (@MITRE.org)]

Pradeep, you should actually comment in JIRA.  Responding to JIRA emails
doesn't work (I think).

To answer your question, the fundamental capabilities in SOLR-2155 made it
into Solr 4.  SOLR-2345 is specifically about using the geodist() function
query in addition to the more awkward method of using the score=distance
local-param. If you search you may see info on that approach, if you can't
yet go to Solr 4.5.

~ David


Pradeep Pujari-4 wrote
> Hi Bill,
> 
> We are using SOLR-2155 patch in solr3.6 for quite long time. This works
> well for us. We are currently migrating to Solr 4.0. Is this SOLR-2345 is
> equivalent of  SOLR-2155 in terms of functionality?
> 
> Thanks
> 
> 
> 
>  From: David Smiley (JIRA) <

> jira@

> >
> To: 

> dev@.apache

>  
> Sent: Tuesday, July 16, 2013 10:20 PM
> Subject: [jira] [Updated] (SOLR-2345) Extend geodist() to support
> MultiValued lat long field
>  
> 
> 
>      [
> https://issues.apache.org/jira/browse/SOLR-2345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> ]
> 
> David Smiley updated SOLR-2345:
> ---
> 
>     Attachment: SOLR-2345_geodist_support_for_RPT.patch
> 
> The attached patch implements the desired functionality.  It depends on
> LUCENE-5118 being applied first.
> 
> This hack wasn't too terrible after all.
>                 
>> Extend geodist() to support MultiValued lat long field
>> --
>>
>>                 Key: SOLR-2345
>>                 URL: https://issues.apache.org/jira/browse/SOLR-2345
>>             Project: Solr
>>          Issue Type: New Feature
>>          Components: spatial
>>            Reporter: Bill Bell
>>            Assignee: David Smiley
>>             Fix For: 4.5
>>
>>         Attachments: SOLR-2345_geodist_refactor.patch,
SOLR-2345_geodist_support_for_RPT.patch
>>
>>
>> Extend geodist() and {!geofilt} to support a multiValued lat,long field
>> without using geohash.
>> sort=geodist() asc
> 
> --
> This message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA
> administrators
> For more information on JIRA, see: http://www.atlassian.com/software/jira
> 
> -
> To unsubscribe, e-mail: 

> dev-unsubscribe@.apache

> For additional commands, e-mail: 

> dev-help@.apache





-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/jira-Updated-SOLR-2345-Extend-geodist-to-support-MultiValued-lat-long-field-tp4078512p4090774.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Joins on the confluence wiki

[David Smiley (@MITRE.org)]

Erick,

Kranti referred to the *Confluence* wiki, in other words, the Solr Reference
Guide.  Am I correct in that only committers can have write access to that?:
https://cwiki.apache.org/confluence/display/solr/Internal+-+Maintaining+Documentation#Internal-MaintainingDocumentation-WhoCanEditThisDocumentation

~ David


Erick Erickson wrote
> Just let us know your Wiki user ID and we'll add you
> to the approved list right away.
> 
> Had some trouble with spam bots a while back so had to go
> this route.
> 
> Thanks for volunteering to help!
> 
> Erick
> 
> 
> On Thu, Sep 12, 2013 at 9:16 PM, Kranti Parisa <

> kranti.parisa@

> >wrote:
> 
>> Guys,
>>
>> Seems there is not wiki page for Joins. I have been using/working Joins
>> and I want to start writing a page for the same on the Confluence wiki.
>> How
>> can I get access for adding/editing the wiki pages?
>>
>> Thanks & Regards,
>> Kranti K Parisa
>> http://www.linkedin.com/in/krantiparisa
>>
>>





-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Joins-on-the-confluence-wiki-tp4089757p4089939.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Welcome Cassandra Targett as Lucene/Solr committer

[David Smiley (@MITRE.org)]

Welcome Cassandra!  And thanks for sharing your background; it's nice to know
more about others in the community.  I'm in the Boston area -- Lowell
specifically.

~ David



-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Welcome-Cassandra-Targett-as-Lucene-Solr-committer-tp4081767p4082233.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

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

[David Smiley (@MITRE.org)]

Oh; I should have read more carefully.  Thanks!
~ David


sarowe wrote
> David, you made your edits after Hoss called the RC1 vote - I was arguing
> for an RC2 based partly on your changes.
> 
> Steve





-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/VOTE-RC1-Release-apache-solr-ref-guide-4-4-pdf-tp4080196p4080489.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

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

[David Smiley (@MITRE.org)]

+1
Thanks Hoss, Cassandra, and to everyone else who contributed!



-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/VOTE-RC2-Release-apache-solr-ref-guide-4-4-pdf-tp4080395p4080488.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

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

[David Smiley (@MITRE.org)]

Darn; I haven't noticed these failures.  I'll investigate.  I need to set up
some sort of email filter alert system so they come to my attention
immediately.

(without knowing what the bug is; it's most likely in the complicated test).

~ David


Policeman Jenkins Server-2 wrote
> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/6066/
> Java: 32bit/jdk1.6.0_45 -server -XX:+UseSerialGC
> 
> 1 tests failed.
> FAILED: 
> org.apache.lucene.spatial.prefix.SpatialOpRecursivePrefixTreeTest.testContains
> {#1 seed=[9166D28D6532217A:472BE5C4B7344982]}
> 
> Error Message:
> Shouldn't match I
> #0:ShapePair(Rect(minX=102.0,maxX=112.0,minY=-36.0,maxY=120.0) ,
> Rect(minX=168.0,maxX=175.0,minY=-1.0,maxY=11.0))
> Q:Rect(minX=0.0,maxX=256.0,minY=-128.0,maxY=128.0)
> 
> Stack Trace:
> java.lang.AssertionError: Shouldn't match I
> #0:ShapePair(Rect(minX=102.0,maxX=112.0,minY=-36.0,maxY=120.0) ,
> Rect(minX=168.0,maxX=175.0,minY=-1.0,maxY=11.0))
> Q:Rect(minX=0.0,maxX=256.0,minY=-128.0,maxY=128.0)
>   at
> __randomizedtesting.SeedInfo.seed([9166D28D6532217A:472BE5C4B7344982]:0)
>   at org.junit.Assert.fail(Assert.java:93)
>   at
> org.apache.lucene.spatial.prefix.SpatialOpRecursivePrefixTreeTest.fail(SpatialOpRecursivePrefixTreeTest.java:287)
>   at
> org.apache.lucene.spatial.prefix.SpatialOpRecursivePrefixTreeTest.doTest(SpatialOpRecursivePrefixTreeTest.java:273)
>   at
> org.apache.lucene.spatial.prefix.SpatialOpRecursivePrefixTreeTest.testContains(SpatialOpRecursivePrefixTreeTest.java:101)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>   at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:597)
>   at
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
>   at
> com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
>   at
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
>   at
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
>   at
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
>   at
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
>   at
> org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
>   at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
>   at
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
>   at
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
>   at
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
>   at
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
>   at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
>   at
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
>   at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
>   at
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
>   at
> com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
>   at
> com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
>   at
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
>   at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
>   at
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
>   at
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
>   at
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
>   at
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
>   at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at
> org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
>   at
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
>   at
> org.apache.lucene.util.TestRuleIgnoreAfterMax

Re: Welcome Han Jiang as a new Lucene/Solr committer

[David Smiley (@MITRE.org)]

Welcome Han Jiang!

~ David



-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Welcome-Han-Jiang-as-a-new-Lucene-Solr-committer-tp4069013p4069120.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Numeric Multi-Valued Doc Values

[David Smiley (@MITRE.org)]

That's a schema issue.  Lucene doesn't really have one so there isn't a
definitive answer there.  For Solr, this ideally should be cleaner but it
isn't, last I checked a month ago.  You could poke around the TrieField code
but in the end you will probably end up making assumptions on your code
being consistent with what TrieField is doing :-/  Perhaps we need a new
JIRA issue to add an indexedToObject(BytesRef):Object method to FieldType. 
The default impl could call indexedToReadable() and return a String.

~ David


Steven Bower wrote
> What is the proper way to convert the value coming from SortedSetDocValues
> for a numeric field (Int/Long/Float/Double) to their actual numeric
> values... Basically I can get the ByteRef filled in with lookupOrd(...)
> but
> what is the proper way to take the contents of the BytesRef and get the
> int/long/etc.. value back from it?
> 
> thanks,
> 
> steve





-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Numeric-Multi-Valued-Doc-Values-tp4065423p4066190.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Numeric Multi-Valued Doc Values

[David Smiley (@MITRE.org)]

-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Numeric-Multi-Valued-Doc-Values-tp4065423p4066189.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: SLF4J Binding Warnings

[David Smiley (@MITRE.org)]

Interesting.  But the sysout-over-slf4j project declares:


> The sysout-over-slf4j module is explicitly not intended to encourage the
> use of System.out or System.err for logging purposes. There is a
> significant performance overhead attached to its use, and as such it
> should be considered a stop-gap for your own code until you can alter it
> to use SLF4J directly, or a work-around for poorly behaving third party
> modules.

As far as Solr is concerned, SLF4J is good, IMO.  Adapters are available to
log to basically anything, and the user is in control of that by providing
their logging jar of choice.

~ David


Robert Muir wrote
> On Thu, May 23, 2013 at 12:29 PM, Shawn Heisey <

> solr@

> > wrote:
> 
>>
>> For logs that are in test code itself, using sysout or syserr is probably
>> a good option.  The Solr code that is being tested will (in most cases)
>> pull in a dependency on slf4j because Logger is ubiquitous.  That's what
>> I
>> was referring to.
>>
>>
> I'm not sure it has to forever. For example, in trunk we could decide to
> use jetty's logging class instead, so solr has no hard dependency on slf4j
> at all.
> If its in the classpath it would get used, but otherwise stuff just goes
> to
> System.err.println.
> 
> Or solr could just use System.err.println, and if someone wants logging
> they can redirect it (e.g.
> http://projects.lidalia.org.uk/sysout-over-slf4j/
> ).
> 
> Lots of possibilities to remove logging jars!





-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/SLF4J-Binding-Warnings-tp4064166p4066182.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Join Queries Scores broken?

[David Smiley (@MITRE.org)]

Hi Kranti,

I think this post belongs on the solr-user list.  Any way, Solr join queries
don't score.  Filter queries don't score either so even if join queries did,
using them in a filter query wouldn't help.  For what it's worth, I
implemented a Solr scoring join query for a customer by basing it off of
scoring join query code in Lucene's "join" module.  You could do the same. 
My requirements were more extensive but if all I needed was a working
scoring join query, then there isn't that much to it.

Cheers,
  David


Kranti™ K K Parisa wrote
> Hi,
> 
> I am trying to score/rank the results based on the boosting values
> specified with the Join queries.
> 
> Example:
> http://localhost:8983/solr/masterCore/select?q=a*&fq=(({!join
> fromIndex=childCore1
> from=parentId to=id v=$subQ1}) OR ({!join fromIndex=childCore2
> from=authorId to=id
> v=$subQ2}))&subQ1=(name:xyz^100)&subQ2=(author:xyz)&fl=id,score
> 
> So the matching documents from first join query should be getting higher
> score than the ones from the second join query.
> 
> But it is not working as expected, do I need to specify any other
> parameters? if it's an issue, shall I create a Jira ticket?
> Thanks & Regards,
> Kranti K Parisa
> http://www.linkedin.com/in/krantiparisa





-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Join-Queries-Scores-broken-tp4065827p4066180.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Including JTS in an Apache project

[David Smiley (@MITRE.org)]

Hi Ahmed,

I faced your conundrum with JTS early last year.  As you know, the Apache
Software Foundation doesn't like it's projects depending on GPL and even
LGPL licensed libraries.  The ASF does not have clear unambiguous language
on how its projects can depend on them in a limited sense.  Different PMCs
(projects) have different standards.  I've heard of one project (CXF?) that
uses Java reflection to use an LGPL library.  I think another downloads the
LGPL library as part of the build, and then the code has a compile-time
dependency (I could be mistaken).  If memory serves, in both cases the
dependency fit an optional role and not a core purpose of the software.  The
Lucene PMC in particular didn't formally vote to my knowledge but there was
a time when it was clear to me that such approaches were not acceptable.

The approach that the Lucene spatial developers took (me, Ryan, Chris) was
to create a non-ASF project called Spatial4j that is ASL licensed. 
Spatial4j *optionally* depends on JTS -- it's only for advanced shapes
(namely polygons) and for WKT parsing. 
https://github.com/spatial4j/spatial4j  BTW, WKT parsing will be handled by
Spatial4j itself in the near future without JTS. Spatial4j is not a subset
of JTS; it critically has things JTS doesn't like a native circle (not a
polygon approximation) and the concept of the world being a sphere instead
of flat ;-)  That's right, JTS, as critical as it is in the world of
open-source spatial, doesn't have any geodetic calculations, just Euclidean. 
Spatial4j adds dateline wrap support to JTS shapes so you can represent Fiji
for example, but not yet Antarctica (no pole wrap).  So I encourage the
Apache Pig project to take a look at using Spatial4j instead of directly
using JTS for the same reasons that the Lucene project uses it.  If you
ultimately decide not to then please let me know why, as I see Spatial4j
being an excellent fit for ASF projects in particular because of the
licensing issue.  

So your statement "Apache Solr *uses* JTS" is incorrect.  No it doesn't, and
nor does Lucene; not at all.  Instead, those projects use Spatial4j, which
has an abstraction (Shape), and it has an implementation of that abstraction
that depends on JTS.  It also has implementations that don't depend on JTS.

p.s. Last week I did a long presentation on Spatial in Lucene/Solr/Spatial4j
and I'd be happy to share the slides with you. The organizers will but they
haven't yet.

~ David Smiley


Ahmed El-dawy wrote
> Hi all,
>  I saw that Apache solr uses JTS (Java Topology Suite) [
> http://www.vividsolutions.com/jts/JTSHome.htm] for supporting a spatial
> data type [http://wiki.apache.org/solr/SolrAdaptersForLuceneSpatial4].
> Using JTS in an Apache project is not a straight forward thing as JTS is
> licensed under LGPL which has some compatibility issued when included in
> an
> Apache project. Now, I need to dome something very similar in another
> Apache project (Pig [http://pig.apache.org/]) and I'm faced with the
> licensing issue. I'm asking for your advice for the best way we can do to
> use JTS without breaking the license issue. Does referring to JTS classes
> from the code of an Apache project without actually including the classes
> violate the license? Do we have to load the classes dynamically (using
> Class#forName) or there is another way to do it?
> Thanks in advance
> 
> Best regards,
> Ahmed Eldawy





-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Including-JTS-in-an-Apache-project-tp4060944p4060969.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: VOTE: solr no longer webapp

[David Smiley (@MITRE.org)]

I feel the same as Shawn; I was quite skeptical until the reasons were
finally given.  And I agree that the war file distribution needs to stick
around longer.  That's a big deal from a user perspective; not something to
happen in a point release.  To be clear, I think a change like this should
happen no sooner than 5.0.

+1 on 5.0
-0 on 4.x

~ David


Shawn Heisey-4 wrote
> On 5/4/2013 2:42 PM, Mark Miller wrote:
>> * super simple improvements, like not having to name space sys props to
>> solr.
>> * releasing an app that is tested and works - already things have come up
>> where something works in jetty and not tomcat and many users struggle
>> with all kinds of problems trying to shove solr into weblogic or other
>> containers. lets get all our users on one set of bits that we ship, not
>> some wonderland of combinations that we don't control - there are real
>> benefits to this!
>> * Deal with SLF4j in a nice way that doesn't cause Robert to claim we
>> broke the war.
>> * what if Solr was actually two processes and not one? what if there was
>> an agent that could start and stop solr? stop and start your cluster with
>> a single command? update your cluster automatically by kicking off a
>> command? The agent could restart Solr? What if things like heap size
>> could live in ZK and out of the box you just had to configure that stuff
>> in one spot? Shouldn't you be able to configure all of Solr rather than
>> rely on users cmd line arguments?
>> * webapps cannot tell what port they are running on except within a
>> request…yuck.
>> * shouldn't we be able to use specific features and improvements that not
>> all containers support? Shouldn't we be able to plug and play the
>> underlying http layer technology?
>> * shouldn't we be able to try and use embedded jetty and its nice
>> integration with guice+restlet? Check out using netty?
>> * why should we ship advertising a format that begs running other apps in
>> the same Solr process! This is a terrible idea for a search engine.
> 
> Those are awesome reasons to switch.  I thought there might be some, and
> now I've seen enough of them to change my vote:
> 
> +1
> 
> If a .war build option is still available for a while, then I think we'd
> be covered.
> 
> I really like the idea of Solr being two processes, as long as it is
> clean and cross-platform.  Does Java support starting another instance
> of the JVM in a "direct" manner, or would it be a case of calling the
> executable with commandline options?
> 
> Thanks,
> Shawn
> 
> 
> -
> To unsubscribe, e-mail: 

> dev-unsubscribe@.apache

> For additional commands, e-mail: 

> dev-help@.apache





-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/VOTE-solr-no-longer-webapp-tp4060604p4060866.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [ANNOUNCE] Solr wiki editing change

[David Smiley (@MITRE.org)]

Please add me to both wikis, userid: DavidSmiley



-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/ANNOUNCE-Solr-wiki-editing-change-tp4050968p4055736.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Possible problem with RAMDirectory; tips please

[David Smiley (@MITRE.org)]

Thanks for that tip Dawid.  I'll consider AspectJ some day; that's an
interesting approach.

So as it turns out, I was wrong when I said that the same shapes etc. were
being tested when I switched the directory via the system property.  I
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.  This makes it difficult to make a
test that uses randomization to "just" change the directory for a given test
run (i.e. for a given seed).  It would be nice if there was a mechanism to
restore the random state so you could restore it from when it was captured
at the beginning of a method call.  This wouldn't just apply to
newDirectory() but to some other similar utility methods.

~ David



-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Possible-problem-with-RAMDirectory-tips-please-tp4054241p4054565.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Possible problem with RAMDirectory; tips please

[David Smiley (@MITRE.org)]

I'll try to make a version of the test that is unrandomized -- I'll index the
exact shapes needed and query for the specific shape using the right
algorithm.  And at that point, I'll try and reduce it.  Simon's right; I'm
looking for debugging tips/strategy advise.  I find it pretty odd that my
test will fail for a particular directory but not others (in the right
circumstances -- i.e. the specific shapes etc.).  That is suspicious -- it
has me wondering if the bug is perhaps not in my code after all since I
don't know what my code (or anyone's Lucene code for that matter) could
possibly be doing that would make the outcome dependent on the directory
implementation.

~ David



-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Possible-problem-with-RAMDirectory-tips-please-tp4054241p4054250.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Possible problem with RAMDirectory; tips please

[David Smiley (@MITRE.org)]

I need a seed to ensure that my test, which uses a lot of randomization,
generates the right randomized shapes.  This particular seed just so happens
to pick RAMDirectory as well, and that's how I first stumbled upon the
problem; all the circumstances were just right.  I'm not manually using "new
RAMDirectory()", I'm letting it get chosen either by default or if I want
something else then picking it via the system property -- "newDirectory()". 
I am aware of the complexities of debugging this by inadvertently altering
what the random seed is at any given moment due to commenting out something
in an attempt to deduce what the problem is. I don't think I fell victim to
that trap because I've been watchful at the moment the assertion occurs,
what the particular random indexed & queried shapes should be.

~ David


Michael McCandless-2 wrote
> Is it a particular seed that shows the failure with RAMDir?
> 
> If so, I think most likely by specifying the directory to ant you are
> effectively altering the random seed?
> 
> If that's it, you can go into LuceneTestCase.java where it has this
> directory logic and keep consuming the randomness but then hardwire
> the directory impl you want?  Be sure to put a // nocommit there too
> ;)
> 
> Mike McCandless
> 
> http://blog.mikemccandless.com
> 
> On Sat, Apr 6, 2013 at 2:09 PM, David Smiley (@MITRE.org)
> <

> DSMILEY@

> > wrote:
>> I've been reworking a randomized test in Lucene spatial; it's pretty
>> hard.
>> One particular failing test is driving me crazy right now.  I figured out
>> that the problem would only occur if the RAMDirectory was chosen, and of
>> course if I created just the right sequence of indexed shapes and query
>> for
>> the right shape, etc... so there's a lot of things that have to be just
>> so
>> for the test to fail.  If the *only* thing I change is
>> -Dtests.directory=RAMDirectory then it fails absolutely every time at the
>> same spot, and if the directory is something else because I set it with
>> the
>> system property, then the test passes.  Could this actually be a bug in
>> my
>> code?  Any tips on how to debug this is highly appreciated.  I can change
>> the codec but that doesn't affect the problem.  I was hoping to use
>> SimpleText codec but I can't easily view the contents of the RAMDirectory
>> :-)
>>
>> All of the code in question is local but if it would help I can post a
>> patch
>> some where.  I haven't narrowed down the problem exactly so it requires
>> setting the random seed.
>>
>> ~ David
>>
>>
>>
>> -
>>  Author:
>> http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
>> --
>> View this message in context:
>> http://lucene.472066.n3.nabble.com/Possible-problem-with-RAMDirectory-tips-please-tp4054241.html
>> Sent from the Lucene - Java Developer mailing list archive at Nabble.com.
>>
>> -
>> To unsubscribe, e-mail: 

> dev-unsubscribe@.apache

>> For additional commands, e-mail: 

> dev-help@.apache

>>
> 
> -
> To unsubscribe, e-mail: 

> dev-unsubscribe@.apache

> For additional commands, e-mail: 

> dev-help@.apache





-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Possible-problem-with-RAMDirectory-tips-please-tp4054241p4054245.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Possible problem with RAMDirectory; tips please

[David Smiley (@MITRE.org)]

I've been reworking a randomized test in Lucene spatial; it's pretty hard. 
One particular failing test is driving me crazy right now.  I figured out
that the problem would only occur if the RAMDirectory was chosen, and of
course if I created just the right sequence of indexed shapes and query for
the right shape, etc... so there's a lot of things that have to be just so
for the test to fail.  If the *only* thing I change is
-Dtests.directory=RAMDirectory then it fails absolutely every time at the
same spot, and if the directory is something else because I set it with the
system property, then the test passes.  Could this actually be a bug in my
code?  Any tips on how to debug this is highly appreciated.  I can change
the codec but that doesn't affect the problem.  I was hoping to use
SimpleText codec but I can't easily view the contents of the RAMDirectory
:-)

All of the code in question is local but if it would help I can post a patch
some where.  I haven't narrowed down the problem exactly so it requires
setting the random seed.

~ David



-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Possible-problem-with-RAMDirectory-tips-please-tp4054241.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Welcome Shalin Shekhar Mangar to the PMC

[David Smiley (@MITRE.org)]

Welcome Shalin!



-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Welcome-Shalin-Shekhar-Mangar-to-the-PMC-tp4053885p4054240.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Opening up FieldCacheImpl

[David Smiley (@MITRE.org)]

Interesting conversation. So if hypothetically Solr's FileFloatSource /
ExternalFileField didn't yet exist and we were instead talking about how to
implement such a thing on the latest 4.x code, then how basically might it
work?  I can see how to implement a Solr CodecFactory ( a SchemaAware one) ,
then a DocValuesProducer.  The CodecFactory implements
NamedInitializedPlugin and can thus get its config info that way.  That's
one approach.  But it's not clear to me where one would wrap AtomicReader
with FilterAtomicReader to use that approach.

~ David


Robert Muir wrote
> On Sat, Mar 23, 2013 at 7:25 AM, Alan Woodward <

> alan@.co

> > wrote:
>>> I think instead FieldCache should actually be completely package
>>> private and hidden behind a UninvertingFilterReader and accessible via
>>> the existing AtomicReader docValues methods.
>>
>> Aha, right, because SegmentCoreReaders already caches XXXDocValues
>> instances (without using WeakReferences or anything like that).
>>
>> I should explain my motivation here.  I want to store various scoring
>> factors externally to Lucene, but make them available via a ValueSource
>> to CustomScoreQueries - essentially a generalisation of FileFloatSource
>> to any external data source.  FFS already has a bunch of code copied from
>> FieldCache, which was why my first thought was to open it up a bit and
>> extend it, rather than copy and paste again.
>>
>> But it sounds as though a nicer way of doing this would be to create a
>> new DocValuesProducer that talks to the external data source, and then
>> access it through the AR docValues methods.  Does that sound plausible? 
>> Is SPI going to make it difficult to pass parameters to a custom
>> DVProducer (data location, host/port, other DV fields to use as primary
>> key lookups, etc)?
>>
> 
> its not involved if you implement via FilterAtomicReader. its only
> involved for reading things that are actually written into the index.
> 
> -
> To unsubscribe, e-mail: 

> dev-unsubscribe@.apache

> For additional commands, e-mail: 

> dev-help@.apache





-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Opening-up-FieldCacheImpl-tp4050537p4051217.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Opening up FieldCacheImpl

[David Smiley (@MITRE.org)]

That would be nice!  There is similar machinery in Solr's ExternalFileField. 
In the spatial module I'd like to cache data per-segment; it's current cache
sucks to say the least.  My current plans are to use BinaryDocValues so I
might not use this proposed machinery after-all but nonetheless I think it's
useful.

~ David


Alan Woodward-2 wrote
> I'm looking at exposing data held externally to an index via a
> ValueSource, and it would be nice to reuse the machinery in FieldCacheImpl
> to cache the data per-segment.  However, it's package-private at the
> moment, which means I can't extend it nicely.  Is there a reason for this? 
> Or should I put up a JIRA to make it public?
> 
> Alan Woodward
> www.flax.co.uk





-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Opening-up-FieldCacheImpl-tp4050537p4050579.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Welcome Stefan Matheis to the PMC

[David Smiley (@MITRE.org)]

Congrats Stefan!  And terrific work on Solr's admin UI -- its both useful and
a pleasure to use.
~ David



-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Welcome-Stefan-Matheis-to-the-PMC-tp4046020p4046073.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

RE: Line length in Lucene/Solr code

[David Smiley (@MITRE.org)]

If 120 is the new maximum, is it also the generally recommended
reflow/line-break for javadocs?  Or should that be 100, or stay at 80?  I
suggest 100.

~ David



-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Line-length-in-Lucene-Solr-code-tp4042685p4042849.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Faster GitHub mirroring

[David Smiley (@MITRE.org)]

Thanks for the FYI!



-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Faster-GitHub-mirroring-tp4029346p4029356.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Solr Bug/Improvement: No-op and no error for Solr /update if no application/xml header

[David Smiley (@MITRE.org)]

I agree; it should return an error instead of mislead/confuse the user.
~ David


Jack Krupansky-2 wrote
> I don’t get any error or any effect from this curl command:
> 
> curl http://localhost:8983/solr/update?commit=true --data-binary '
> 
> 
> sku:td-01
> 
> 
> '
> 
> But, if I add the xml header, it works fine:
> 
> curl http://localhost:8983/solr/update?commit=true -H "Content-Type:
> application/xml" --data-binary '
> 
> 
> sku:td-01
> 
> 
> '
> 
> It would be nice if Solr would default to application/xml, but a friendly
> error return would be better than a no-op in this case.
> 
> FWIW, curl –v shows this header being sent if I don’t specify it
> explicitly:
> 
> Content-Type: application/x-www-form-urlencoded
> 
> -- Jack Krupansky





-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Solr-Bug-Improvement-No-op-and-no-error-for-Solr-update-if-no-application-xml-header-tp4027800p4027877.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Solr faceting vs. Lucene faceting

[David Smiley (@MITRE.org)]

Shai Erera wrote
> Yonik, unlike Solr facets (which manage everything in the search index),
> the Lucene module comes with a sidecar taxonomy index, so e.g. when Solr
> replicates shards, it will need to replicate one other index files. That's
> the big difference, the rest are miniscule I think. And of course, Solr
> has
> a much higher level API than Lucene, so we'll need to translate those APIs
> to the facets module.

Shai,
RE: Sidecar index --  That's a huge difference and a shortcoming; no?  Do
you somehow take care to avoid a stale view on the sidecar index during a
commit?

On the upside; if this does proper hierarchical faceting then a Solr adapter
for it would be awesome.

~ David



-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Solr-faceting-vs-Lucene-faceting-tp4025577p4025928.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Active 4.x branches?

[David Smiley (@MITRE.org)]

Those are good points Yonik.  I guess I don't know what to think anymore.


Yonik Seeley-4 wrote
> On Thu, Nov 29, 2012 at 1:24 AM, David Smiley (@MITRE.org)
> <

> DSMILEY@

> > wrote:
>> Maybe we should have a
>> roster somewhere of parts of the codebase that have an owner.
> 
> Taking ownership is a mindset, and is very different from any kind of
> recognized "having ownership".
> We shouldn't tag areas as "owned" by someone, as that could discourage
> others getting involved in that area.
> It might also encourage deference to the "owner", which would also be
> a bad thing.  We sometimes naturally defer to someone with more
> experience in an area than we have, but it should continue to be on an
> informal case-by-case basis.
> 
>> It could be
>> useful to people not "in the know" on who to contact
> 
> The right contact point is this mailing list.
> There's already way to much off-list (and off IRC channel)
> collaboration that goes on IMO.
> 
> -Yonik
> http://lucidworks.com
> 
> -
> To unsubscribe, e-mail: 

> dev-unsubscribe@.apache

> For additional commands, e-mail: 

> dev-help@.apache





-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Active-4-x-branches-tp4022609p4023246.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Active 4.x branches?

[David Smiley (@MITRE.org)]

Robert Muir wrote
>>> You generally have many transients and an active smaller core. I think
> this is not at all uncommon.
> 
> I think it significantly helps when we have committers that unofficially
> "take ownership" over certain areas, for lack of a better word. Just
> meaning they look out for it and know it well and so its easier for them
> to
> review and commit people's patches. They are way more productive here than
> old-timer busy core developers because that area of the codebase becomes
> their itch. This lets us scale better.
> 
> So with the codebase this big, I'm not concerned with how many people are
> "core". I think its even better to have lots of people that look out for
> specific areas and know them well. I'm interested in ways we can encourage
> more of this.

I agree with this a lot.  Clearly I "own" spatial.  Maybe we should have a
roster somewhere of parts of the codebase that have an owner.  It could be
useful to people not "in the know" on who to contact, and perhaps it might
inspire more involvement for less involved committers. The other day I
assigned myself to the "modules/spatial" component in Jira, overwriting
Ryan.  Nobody is assigned to any other component.  I'm not sure if it's a
good idea to auto-assign a Jira issue by component lead or not as it might
suggest that person intends to work on it soon.  But, it at least would more
actively trigger awareness of an issue than might slip through the cracks,
and frustrate a contributor.  Hopefully the Jira notification scheme
notifies a component lead on issue creation.

~ David



-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Active-4-x-branches-tp4022609p4023183.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

RE: dismax vs edismax

[David Smiley (@MITRE.org)]

I absolutely agree with your first point.  For second point, I agree for 
defType (so that it affects 'q') but not all the other numerous spots.  As far 
as pushing down into Lucene; if you haven't noticed, Solr now has its own copy 
of the Lucene's query parser so it can customize it.  This is a good thing that 
was inevitable IMO.
~ David

From: Jack Krupansky-2 [via Lucene] [ml-node+s472066n4022841...@n3.nabble.com]
Sent: Wednesday, November 28, 2012 1:07 AM
To: Smiley, David W.
Subject: Re: dismax vs edismax

My view is that if we simply added an option to edismax to restrict the
syntax to the very limited syntax of dismax, then we could have one, common
xdismax query parser.

And then, why not simply rename the current Solr query parser to "classic"
and make the new xdismax be the default Solr query parser.

And then... push a lot of the so-called "Solr-specific" features down into
the Lucene query parser (abstracting away the specifics of Solr schema, Solr
plugin, Solr parameter format, etc.) and then we can have one, unified query
parser for Lucene and Solr. But... not everyone is persuaded!

-- Jack Krupansky

-Original Message-
From: David Smiley (@MITRE.org)
Sent: Tuesday, November 27, 2012 11:43 PM
To: [hidden email]
Subject: dismax vs edismax

It was my hope that by now, the dismax & edismax distinction would be a
thing
of the past, such that we'd simply call this by one name, simply "dismax".
>From memories of various JIRA commentary, Jan wants this too and made great
progress enhancing edismax, but Hoss pushed back on edismax overtaking
dismax as "the" one new dismax.  I see this as very unfortunate, as having
both complicates things and makes it harder to write them in books ;-)  I'd
love to simply say "dismax" without having to say "edismax" or wonder if
when someone said "dismax" they meant "edismax", etc.  Does anyone see this
changing / progressing?

~ David



-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com/dismax-vs-edismax-tp4022834.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


-
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]




If you reply to this email, your message will be added to the discussion below:
http://lucene.472066.n3.nabble.com/dismax-vs-edismax-tp4022834p4022841.html
To unsubscribe from dismax vs edismax, click 
here<http://lucene.472066.n3.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4022834&code=RFNNSUxFWUBtaXRyZS5vcmd8NDAyMjgzNHwxMDE2NDI2OTUw>.
NAML<http://lucene.472066.n3.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>




-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/dismax-vs-edismax-tp4022834p4022957.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

dismax vs edismax

[David Smiley (@MITRE.org)]

It was my hope that by now, the dismax & edismax distinction would be a thing
of the past, such that we'd simply call this by one name, simply "dismax". 
>From memories of various JIRA commentary, Jan wants this too and made great
progress enhancing edismax, but Hoss pushed back on edismax overtaking
dismax as "the" one new dismax.  I see this as very unfortunate, as having
both complicates things and makes it harder to write them in books ;-)  I'd
love to simply say "dismax" without having to say "edismax" or wonder if
when someone said "dismax" they meant "edismax", etc.  Does anyone see this
changing / progressing?

~ David



-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/dismax-vs-edismax-tp4022834.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: svn commit: r1413832 - in /lucene/dev/trunk/lucene/spatial/src/test/org/apache/lucene/spatial: SpatialExample.java StrategyTestCase.java TestTestFramework.java

[David Smiley (@MITRE.org)]

Hi Dawid.
There's an ant build file that looks for Test*, *Test, and EXCLUDES '$'
hence no inner class.
I wish the test infrastructure simply scanned all test classes in test paths
for @Test or JUnit Testcase subclass.  After all, the vast majority of
classes in /test/** are going to be tests.  No big deal.

~ David



-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Re-svn-commit-r1413832-in-lucene-dev-trunk-lucene-spatial-src-test-org-apache-lucene-spatial-Spatiala-tp4022453p4022455.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Trying out the commit bot tagger at a larger scale

[David Smiley (@MITRE.org)]

Mark,
Do I need to do anything for the bot to make its comment, aside from the
commit?  I just made a commit to both branches.  How much delay is there /
i.e. what's its schedule?
~ David



-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Trying-out-the-commit-bot-tagger-at-a-larger-scale-tp4021178p4022451.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

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

[David Smiley (@MITRE.org)]

If svn:ignore is set to '*' at the top level project, then ant precommit won't 
complain about dirty files that exist there, such as patch files, notes to 
myself, and whatever else.  The wildcard should not conflict with build.xml or 
the other few checked-in files and folders being in source control -- it should 
have no impact.  Likewise, I would also find it convenient to set svn:ignore to 
'*' on dev-tools/idea/.idea/  I recognize the point of dirty file checking in 
ant precommit but I would prefer it be reigned in a bit.

~ David

On Nov 26, 2012, at 2:38 PM, sarowe [via Lucene] wrote:

I guess there are two classes of things here: new non-ignored 
non-svn-controlled files; and modifications to svn-controlled files.

My point about svn:ignore was that we could use it to handle the non-ignored 
non-svn-controlled files case.

I guess you're talking about the svn-controlled modified files case?  And the 
fact that svn:ignore=* doesn't cover this case?  If so, okay, that makes sense. 
 If not, can you increase your word count a little and help me understand?

Steve

On Nov 26, 2012, at 2:25 PM, David Smiley (@MITRE.org) <[hidden 
email]> wrote:

> AFAIK if you set svn:ignore * then it won't ignore files and directories that 
> are in source control.
>
> ~ David
>
> On Nov 26, 2012, at 1:41 PM, sarowe [via Lucene] wrote:
>
>> I've always put patches up one level from checked out dirs: svn diff > 
>> ../PROJECT-.patch; patch -p0 < ../PROJECT-.patch.
>>
>> For stuff that should be ignored by everybody (or that wouldn't cause 
>> trouble for others), we could add them to the svn:ignore list for the 
>> directory they're in?
>>
>> Alternatively, I'd support a set of individually-settable wildcard 
>> exceptions to the dirty-is-bad rule, maybe via a sysprop?
>>
>> Steve
>>
>> On Nov 26, 2012, at 1:30 PM, "Smiley, David W." <> href="x-msg://149/user/SendEmail.jtp?type=node&node=4022419&i=0" 
>> target="_top" rel="nofollow" link="external">[hidden email]> wrote:
>>
>> > 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 different than the one in source control, and more easily 
>> > commit desirable changes.  I might stop doing this if this were the only 
>> > thing in my way from "ant precommit".
>> >
>> > FWIW my solution has been to modify the build script to not do the dirty 
>> > check :-)
>> >
>> > ~ David
>> >
>> > On Nov 26, 2012, at 11:09 AM, Michael McCandless wrote:
>> >
>> >> I think the idea is to catch files you forgot to svn add.
>> >>
>> >> For IDE files, you should just svn ignore them?
>> >>
>> >> Mike McCandless
>> >>
>> >> http://blog.mikemccandless.com<http://blog.mikemccandless.com/>
>> >>
>> >> On Mon, Nov 26, 2012 at 9:46 AM, David Smiley (@MITRE.org)
>> >> <> >> href="x-msg://149/user/SendEmail.jtp?type=node&node=4022419&i=1" 
>> >> target="_top" rel="nofollow" link="external">[hidden email]> wrote:
>> >>> "ant precommit" will check if the source tree is "dirty" (i.e. contains 
>> >>> files
>> >>> not in source control) and stop with a failure if so.  I find that rather
>> >>> annoying since I've usually got a variety of .patch files and IDE config
>> >>> changes.  What is the rationale behind this check?  How do people usually
>> >>> deal with it?  Perhaps if I do my real development on another checkout 
>> >>> (git
>> >>> based), I could then patch on the svn one for the commit.  Pretty 
>> >>> annoying
>> >>> though, and the 4x port is yet another step.  There sure is a lot of 
>> >>> burden
>> >>> to getting commits in.  I no longer care to improve little javadoc and 
>> >>> typo
>> >>> stuff.
>> >>>
>> >>> ~ David
>> >>>
>> >>>
>> >>>
>> >>> -
>> >>> Author: 
>> >>> http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
>> >>

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

[David Smiley (@MITRE.org)]

AFAIK if you set svn:ignore * then it won't ignore files and directories that 
are in source control.

~ David

On Nov 26, 2012, at 1:41 PM, sarowe [via Lucene] wrote:

I've always put patches up one level from checked out dirs: svn diff > 
../PROJECT-.patch; patch -p0 < ../PROJECT-.patch.

For stuff that should be ignored by everybody (or that wouldn't cause trouble 
for others), we could add them to the svn:ignore list for the directory they're 
in?

Alternatively, I'd support a set of individually-settable wildcard exceptions 
to the dirty-is-bad rule, maybe via a sysprop?

Steve

On Nov 26, 2012, at 1:30 PM, "Smiley, David W." <[hidden 
email]> wrote:

> 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 different than the one in source control, and more easily commit desirable 
> changes.  I might stop doing this if this were the only thing in my way from 
> "ant precommit".
>
> FWIW my solution has been to modify the build script to not do the dirty 
> check :-)
>
> ~ David
>
> On Nov 26, 2012, at 11:09 AM, Michael McCandless wrote:
>
>> I think the idea is to catch files you forgot to svn add.
>>
>> For IDE files, you should just svn ignore them?
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com<http://blog.mikemccandless.com/>
>>
>> On Mon, Nov 26, 2012 at 9:46 AM, David Smiley (@MITRE.org)
>> <[hidden email]> 
>> wrote:
>>> "ant precommit" will check if the source tree is "dirty" (i.e. contains 
>>> files
>>> not in source control) and stop with a failure if so.  I find that rather
>>> annoying since I've usually got a variety of .patch files and IDE config
>>> changes.  What is the rationale behind this check?  How do people usually
>>> deal with it?  Perhaps if I do my real development on another checkout (git
>>> based), I could then patch on the svn one for the commit.  Pretty annoying
>>> though, and the 4x port is yet another step.  There sure is a lot of burden
>>> to getting commits in.  I no longer care to improve little javadoc and typo
>>> stuff.
>>>
>>> ~ David
>>>
>>>
>>>
>>> -
>>> Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
>>> --
>>> View this message in context: 
>>> http://lucene.472066.n3.nabble.com/ant-precommit-annoyed-with-checkout-is-dirty-tp4022362.html
>>> Sent from the Lucene - Java Developer mailing list archive at 
>>> Nabble.com<http://Nabble.com>.
>>>
>>> -
>>> To unsubscribe, e-mail: [hidden 
>>> email]
>>> For additional commands, e-mail: [hidden 
>>> email]
>>>
>>
>> -
>> To unsubscribe, e-mail: [hidden 
>> email]
>> For additional commands, e-mail: [hidden 
>> email]
>>
>
>
> -
> To unsubscribe, e-mail: [hidden 
> email]
> For additional commands, e-mail: [hidden 
> email]
>


-
To unsubscribe, e-mail: [hidden 
email]
For additional commands, e-mail: [hidden 
email]




If you reply to this email, your message will be added to the discussion below:
http://lucene.472066.n3.nabble.com/ant-precommit-annoyed-with-checkout-is-dirty-tp4022362p4022419.html
To unsubscribe from ant precommit; annoyed with "checkout is dirty", click 
here<http://lucene.472066.n3.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4022362&code=RFNNSUxFWUBtaXRyZS5vcmd8NDAyMjM2MnwxMDE2NDI2OTUw>.
NAML<http://lucene.472066.n3.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>





-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/ant-precommit-annoyed-with-checkout-is-dirty-tp4022362p4022431.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

ant precommit; annoyed with "checkout is dirty"

[David Smiley (@MITRE.org)]

"ant precommit" will check if the source tree is "dirty" (i.e. contains files
not in source control) and stop with a failure if so.  I find that rather
annoying since I've usually got a variety of .patch files and IDE config
changes.  What is the rationale behind this check?  How do people usually
deal with it?  Perhaps if I do my real development on another checkout (git
based), I could then patch on the svn one for the commit.  Pretty annoying
though, and the 4x port is yet another step.  There sure is a lot of burden
to getting commits in.  I no longer care to improve little javadoc and typo
stuff.

~ David



-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/ant-precommit-annoyed-with-checkout-is-dirty-tp4022362.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Custom DocValues Source -- what's involved?

[David Smiley (@MITRE.org)]

Based on an IM chat with Simon, it appears that doing a custom DocValues
Source subclass is ultimately more work than developing my own custom cache
per-segment, initializing the initial data out of DV on-disk.  The challenge
(for me) is to figure out how to do that.  I'll look at FieldCache & DV
internals for inspiration.

Thanks Simon.

~ David



-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Custom-DocValues-Source-what-s-involved-tp4021225p4021422.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Custom DocValues Source -- what's involved?

[David Smiley (@MITRE.org)]

Hi Adrien.

I've been vaguely following LUCENE-4547.  Wether or not there is official
multi-valued support in DocValues, my question pertains to my ability to
customize a particular in-memory format to my liking.  I'd like to know
what's involved.  I'm trying to address variable values per document, not
fixed.

~ David



-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Custom-DocValues-Source-what-s-involved-tp4021225p4021414.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Update Solr website with description of 4.0 features

[David Smiley (@MITRE.org)]

Nice Jan.  Couple comments:

1.
"You put documents in it (called "indexing") via XML, JSON or binary over
HTTP."

The reference to "binary" in this way is odd, and likewise for the sentence
that follows it.  Perhaps:

"You put documents in it (called "indexing") by sending them over HTTP in
either an XML format, JSON or an efficient binary encoding."

2. You chose to capitalize a lot of words -- wouldn't be my choice as its
suggestive that some things are well known concepts "Real Data Schema".  But
some aren't consistently capitalized.  Consistency 1st, and I vote to remove
all the excessive capitalization except for first letter of a bullet or
headings where it's needed.


I didn't read all of it; it's kinda long.

~ David



-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Update-Solr-website-with-description-of-4-0-features-tp4020176p4020360.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Solr FieldType support for multiple values

[David Smiley (@MITRE.org)]

I'm working with Lucene 4's DocValues in a Solr app, but using it to store
multiple values encoded into a byte array.  Unfortunately, Solr's
DocumentBuilder code passes each value individually to the FieldType calling
createField() for each value, and so the FieldType never sees all the values
for a given document at once.  My short-term solution that avoids hacking
Solr is to have a special UpdateRequestProcessor that will combine the
values into a special object that the FieldType will get.  It's inelegant.

Instead, perhaps have a method on FieldType like isMultiValueAware() to
indicate that the "value" parameter to createField(s) is to be a Collection
when multiple values are passed.  Just an idea, there are other ways to do
it.

Comments?

~ David



-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Solr-FieldType-support-for-multiple-values-tp4020106.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Apache Git mirror

[David Smiley (@MITRE.org)]

Simon,
Your response confuses me.

"3. pull into trunk only from upstream"

Do you mean a local branch "trunk", and coming from apache?

"... and push to github"

What; you can push to github's mirror?  I thought it was read-only?

And do you mind telling me/us how you take a change you commit to trunk and
back-port to 4x (assuming no conflicts) with git?  With svn it involves an
"svn merge" on 4x referencing my commit revision on trunk.  I know my
question is academic for normal git but this git svn double-mirror setup is
odd.

Any way... seeing you guys use git as committers is encouraging as I thought
the git side simply is too 2nd class citizen for Lucene/Solr to be effective
for committers.  Guess not.  I'll have to do what Simon's doing.  Woohoo! 
Hopefully it's okay to post git patches to JIRA instead of subversions's;
I've heard of incompatibility issues but if it's my issue then I'm the one
committing any way so I guess it won't usually be a problem.

~ David



-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Apache-Git-mirror-tp4019552p4019646.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Commit tags in JIRA

[David Smiley (@MITRE.org)]

+1 Cool.



-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Commit-tags-in-JIRA-tp4019500p4019518.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Source Control

[David Smiley (@MITRE.org)]

+1 I'm definitely in favor of moving to git.  I've gotten past the learning
curve hurdle and I appreciate its benefits.

The real challenge, I think, is figuring out how we can get real
collaboration like what is possible on GitHub, without actually truly being
on GitHub.  Maybe Atlassian's new Stash? 
http://www.atlassian.com/software/stash/  It'd be free for the ASF.

~ David



-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Source-Control-tp4016207p4016542.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Welcome Alan Woodward as Lucene/Solr committer

[David Smiley (@MITRE.org)]

Welcome Alan!  You've been improving challenging parts of Lucene.

~ David



-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Welcome-Alan-Woodward-as-Lucene-Solr-committer-tp4014132p4014222.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: VOTE: release 4.0 (take two)

[David Smiley (@MITRE.org)]

I just got it committed to the 4.0 release branch, after I ran tests.

I didn't add a CHANGES.txt entry because this is basically a bug to an
existing entry that is already post-beta (SOLR-3304).

~ David



-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/VOTE-release-4-0-take-two-tp4010808p4011273.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: VOTE: release 4.0 (take two)

[David Smiley (@MITRE.org)]

Does this mean a re-spin?

I have a low-risk but high impact (in terms of features) bug-fix I would
like to get in to 4.0:  https://issues.apache.org/jira/browse/LUCENE-
but I did not want to put the breaks on any release that was being voted on.

~ David 



-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/VOTE-release-4-0-take-two-tp4010808p4011255.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: VOTE: release 4.0

[David Smiley (@MITRE.org)]

Wow; that looks like a serious issue to me.



-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/VOTE-release-4-0-tp4009770p4009941.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Spatial field names in Solr

[David Smiley (@MITRE.org)]

Hi Jack,

Thanks for your interest. Each SpatialStrategy has its pros and cons.  I'm
working through creating slides for a conference today in fact: 
http://www.basistech.com/search-conference/presentations/   Now that the
Solr adapters are committed, I'll be focusing more on documentation.  That
means the wiki, and javadoc comments on the SpatialStrategy impls to
indicate how each works.

~ David



-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Spatial-field-names-in-Solr-tp4008769p4008787.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: 4.0 planning

[David Smiley (@MITRE.org)]

Hi Rob.
I think it's fairly critical that at least some of the Solr spatial adapters
get committed SOLR-3304.  I've been working on it and related issues like
LUCENE-4208.
~ David



-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/4-0-planning-tp4006692p4007774.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Federated Search - jira issues

[David Smiley (@MITRE.org)]

Hi Jacek,

This strikes me as a project that would exist separate to Solr because it
would have little to do with it.  In federated search, you are searching
multiple search platforms of ideally any flavor.  Why base the federated
search platform on any one of these (e.g. Solr)?  I think there is little of
Solr internally that would be re-used if you were federating to other
platforms and not searching Lucene/Solr itself.

~ David Smiley



-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Federated-Search-jira-issues-tp4002796p4003023.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: VOTE: 4.0-BETA

[David Smiley (@MITRE.org)]

Can you please remind us on the ramifications of a beta release for us
developers?  In particular, I mean are there limitations on the sorts of
changes?  The alpha introduced no index change, for example.  Sorry if
you've answered this before but I had trouble looking for it.

Cheers,
~ David



-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/VOTE-4-0-BETA-tp3999508p3999583.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Move ValueSourceFilter to query module?

[David Smiley (@MITRE.org)]

It turns out Solr has a ValueSourceRangeFilter that I think should be ported
over.  I'll create an issue:
https://issues.apache.org/jira/browse/LUCENE-4251



-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Move-ValueSourceFilter-to-query-module-tp3996792p3996899.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Move ValueSourceFilter to query module?

[David Smiley (@MITRE.org)]

Ok.  I'll just go ahead and move it, and change to inclusive edge.  If you
want to add features like that then go for it.  Mostly I felt the class
needed a better home.

~ David


Martijn v Groningen-2 wrote
> 
> +1 Good idea. I think that there also should be other implementations
> for the different primitive types.
> Maybe the inclusive or exclusive filtering can be a boolean option?
> 
> Martijn
> 
> On 23 July 2012 19:37, Smiley, David W.  wrote:
>> 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 the
>> source, by the way:
>> ...
> 




-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Move-ValueSourceFilter-to-query-module-tp3996792p3996894.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [JENKINS] Lucene-Solr-4.x-Windows-Java6-64 - Build # 419 - Failure!

[David Smiley (@MITRE.org)]

Thank you Robert!



-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/JENKINS-Lucene-Solr-4-x-Windows-Java6-64-Build-419-Failure-tp3996835p3996843.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

RE: [JENKINS] Lucene-Solr-trunk-Linux-Java6-64 - Build # 1078 - Failure!

[David Smiley (@MITRE.org)]

FYI I fixed this javadoc warning in recent commits.

-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/JENKINS-Lucene-Solr-trunk-Linux-Java6-64-Build-1078-Failure-tp3991771p3991951.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Welcome Greg Bowyer

[David Smiley (@MITRE.org)]

Welcome Greg!  Merry committing.
~ David

-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Welcome-Greg-Bowyer-tp3990688p3990872.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: remove "via"

[David Smiley (@MITRE.org)]

-1 to remove all "via"
I agree with the opinions expressed in detail by Mark and Eric.  But I don't
think a committer should feel obliged to add their name if their involvement
seemed particularly light in their opinion.
~ David

-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/remove-via-tp3987871p3988237.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Contribute 4.0 NRT source

[David Smiley (@MITRE.org)]

Nagendra,

Simply open a JIRA issue and attach a patch.  Lucene/Solr development
largely centers around JIRA issues via the comments.

Ideally you should provide tests as part of your patch; it certainly won't
be committed if sufficient tests are never furnished.  If your NRT
implementation really works, then I suppose you could modify existing tests
to do an NRT commit, then those tests should work.  I am not suggesting
modifying every test, instead I am suggesting modifying a solrconfig.xml
used in many tests or modify some test infrastructure code to trigger a
commit via your method vs. the standard path.  Even if this isn't committed
as such (e.g. committing all tests to do NRT), seeing existing tests pass
will give confidence in your approach.

NRT isn't my area of expertise, but I strongly suspect there are critical
false assumptions with your approach if Yonik et. all didn't use this
approach.  For example, you speak of not needing to invalidate caches
associated with SolrIndexSearcher on an NRT commit.  But shouldn't most of
those caches be invalid if you are committing new data you want searchable? 
An example is the UnInvertedField cache for faceting on multi-valued fields. 
Anyway; this is a conversation better done in JIRA because it is more
traceable to your contribution.

~ David

-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Contribute-4-0-NRT-source-tp3986838p3986845.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

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

[David Smiley (@MITRE.org)]

And for those that are curious, the difference between the valid jar (as
identified by the checksum sha1 in Solr) and the one I had with a different
checksum, is that the "bad" one was built ~40 seconds earlier, as reflected
in a comment date in
META-INF/maven/commons-fileupload/commons-fileupload/pom.properties

-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/CHECKSUM-FAILED-for-commons-fileupload-1-2-1-jar-tp3984727p3984756.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Ant version for building Solr

[David Smiley (@MITRE.org)]

I noticed that Solr's README.txt says to use Ant 1.7 and explicitly NOT Ant
1.8:
https://svn.apache.org/repos/asf/lucene/dev/trunk/solr/README.txt

Is it because of this?:
http://lucene.472066.n3.nabble.com/test-output-is-sometimes-truncated-td3893614.html

In any case, I think the README should reference a JIRA issue as to what the
problem is, for context.

~ David

-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Ant-version-for-building-Solr-tp3931419p3931419.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: switch jars to ivy mechanism?

[David Smiley (@MITRE.org)]

+1 absolutely.  I'm not a fan of binaries in source control when it can be
avoided, and ivy (and maven) help.

-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/switch-jars-to-ivy-mechanism-tp3862513p3863559.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Remove old Solr UI from /trunk?

[David Smiley (@MITRE.org)]

+1 on removal of the old UI from trunk

-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Remove-old-Solr-UI-from-trunk-tp3802540p3804136.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Welcome Stefan Matheis

[David Smiley (@MITRE.org)]

Welcome Stefan.
I'm glad we have someone we can assign to Solr's UI, and perhaps you can
assist on the Lucene's website.  Hmmm, even the "/browse" UI too -- plenty
to work on :-)  Hey, just curious, have you tried AJAX-Solr?  I've been
using it a lot lately and I'm curious as to your reaction.

~ David

-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Welcome-Stefan-Matheis-tp3788650p3796717.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: lucene-solr pull request: Fixing typo in example schema: 'salves' => 'slaves'

[David Smiley (@MITRE.org)]

Ok, that's disappointing.  So much for ASF projects being part of the social 
coding revolution.  It's a big deal, by the way.  When people ask me what it's 
all about, I point them to this blob post by the Springframework team: 
http://blog.springsource.com/2010/12/21/social-coding-in-spring-projects/
I suspect you are enlightened Mark but others reading our conversation might 
not be.

So this guy's patch, the one I replied to, is a typo amounting to two 
characters.  Are there ASF guidelines on size of contributions?  Wether 
guidelines exist or not, IANAL but I believe there are practical considerations 
on the size of patches to not concern yourself with copyright.  I've seen 
estimates before ranging from 20-100 lines of code.

~ David

On Feb 20, 2012, at 11:07 AM, Mark Miller-3 [via Lucene] wrote:

I think the problem is around the ASF's thoughts on what it means to contribute 
a patch in JIRA and click the check box about donating. They seem to find that 
important, and you don't have the same mechanism when grabbing pull requests 
from github.

On Feb 20, 2012, at 10:56 AM, David Smiley (@MITRE.org) wrote:

> Cool; pull-requests via GitHub.  Has anyone reacted to one of these messages
> and applied the change before?  If so what was the process?  Since
> lucene-solr is a mirror, is it impossible?
>
> ~ David
>
> -
> Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
> --
> View this message in context: 
> http://lucene.472066.n3.nabble.com/lucene-solr-pull-request-Fixing-typo-in-example-schema-salves-slaves-tp3760050p3761098.html
> Sent from the Lucene - Java Developer mailing list archive at 
> Nabble.com<http://Nabble.com>.
>
> -
> To unsubscribe, e-mail: [hidden 
> email]
> For additional commands, e-mail: [hidden 
> email]
>

- Mark Miller
lucidimagination.com<http://lucidimagination.com>












-
To unsubscribe, e-mail: [hidden 
email]
For additional commands, e-mail: [hidden 
email]




If you reply to this email, your message will be added to the discussion below:
http://lucene.472066.n3.nabble.com/lucene-solr-pull-request-Fixing-typo-in-example-schema-salves-slaves-tp3760050p3761133.html
To unsubscribe from lucene-solr pull request: Fixing typo in example schema: 
'salves' => 'slaves', click 
here<http://lucene.472066.n3.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=3760050&code=RFNNSUxFWUBtaXRyZS5vcmd8Mzc2MDA1MHwxMDE2NDI2OTUw>.
NAML<http://lucene.472066.n3.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>



-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/lucene-solr-pull-request-Fixing-typo-in-example-schema-salves-slaves-tp3760050p3761181.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

Re: lucene-solr pull request: Fixing typo in example schema: 'salves' => 'slaves'

[David Smiley (@MITRE.org)]

Cool; pull-requests via GitHub.  Has anyone reacted to one of these messages
and applied the change before?  If so what was the process?  Since
lucene-solr is a mirror, is it impossible?

~ David

-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/lucene-solr-pull-request-Fixing-typo-in-example-schema-salves-slaves-tp3760050p3761098.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Welcome Sami Siren as committer

[David Smiley (@MITRE.org)]

Congrats Sami!

-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Welcome-Sami-Siren-as-committer-tp3758207p3758804.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Welcome Christian Moen as committer

[David Smiley (@MITRE.org)]

A belated welcome Christian!  (I'm new too)

-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Welcome-Christian-Moen-as-committer-tp3745203p3749498.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

RE: Welcome James Dyer

[David Smiley (@MITRE.org)]

A belated welcome!  (I'm new too)

-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Welcome-James-Dyer-tp3732469p3749495.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

CMS peer review process

[David Smiley (@MITRE.org)]

What shall be the procedure of peer review of CMS website changes? Is it
examine patches in JIRA just like source code is, or is it to commit changes
and observe them on the staging server http://lucene.staging.apache.org/ ? 
(or perhaps it depends)

I like these things about the CMS:
* Stuff is staged first, providing an opportunity to revert or modify
something before it's public (published).
* The staging server means people can visually see the effect.  Fairly
important for a CMS.
* Being SVN based, if someone wants to see what I did, they can simply use
conventional SVN tooling.

IMO, because of these benefits, we probably don't need to bother with using
patches and JIRA.

p.s. I already did a quick edit to the website to get my name in the
committer list.  It's staged; I don't have publishing permissions (AFAIK, I
didn't try).

~ David

-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/CMS-peer-review-process-tp3749488p3749488.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [DISCUSS] New Website

[David Smiley (@MITRE.org)]

Grant; did you miss my JIRA issue to add the book info?
https://issues.apache.org/jira/browse/SOLR-3096

~ David

-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/DISCUSS-New-Website-tp3704403p3721786.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Welcome David Smiley

[David Smiley (@MITRE.org)]

Wow! It is truly an honor to be selected by the Lucene PMC to join the
committer ranks.  You are a top notch team of coders working on one of the
most important open-source projects.

About me:

My technical background is all tiers of web development with a focus on the
middle tier and Java.  Of course I have expertise in Lucene and Solr but I
also focus on geospatial matters as well as threading / concurrency.  I like
solving hard interesting problems.

I am employed full time by The MITRE Corporation, a US federally funded
non-profit organization in which I mostly work in the defense sector. I've
been with MITRE for ~14 years. I've been fortunate lately to work on
projects that fund my open-source geospatial work.  I conduct Solr training
at MITRE (1 day and 2-day classes), and I'm sort of a search consultant
within MITRE, advising MITRE and its government clients.  For 6 months, I
have also been working part-time for OpenSource Connections as a search
consultant.

At home, I'm married with two kids: Adeline who is 10 months old (she's in
my arms sleeping as I write this) and Camille who is 2 years 10 months old. 
I don't know how I found the time to write a book, but now that it's done,
I'm on full parental duty when at home.  For fun, I like to follow Starcraft
2 professional e-sports.  It's conveniently something I can do while I hold
a baby; playing the game isn't, unfortuantely.

I look forward to meeting you all at Lucene Revolution in May!  I live close
by in Lowell.

Cheers,
  David Smiley

-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Welcome-David-Smiley-tp3717248p3718969.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [DISCUSS] New Website

[David Smiley (@MITRE.org)]

The new site looks awesome!  Thanks so much for your efforts, Grant.

I see you didn't get a chance to incorporate the 3 Packt books to the Solr
site.  These need to be featured on Solr's front page for the ASF to collect
a cut of the book sales.  I'm willing to help with this aspect of the
website.  What do you think about adding an entry to the slideshow, at the
end for all 3 books?  And how about a menu choice under "Resource" for all 3
books called "Books" that would go to a page similar to the news page with 3
entries chronologically?  By the way, what contstitutes a "resource" seems a
little dubious / arbitrary, but I do think books definitely belong here.

~ David

-
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/DISCUSS-New-Website-tp3704403p3711015.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: edismax and wildcards

[David Smiley (@MITRE.org)]

Ugh, that sucks. I think wildcards & fuzzy queries should be configurable
options of edismax. It strikes me as a bug that the wildcard & fuzzy
operators were applied to all words.  I don't think it's up for the client
application layer to do something about it this since; this is a Solr
problem.  Did you file a bug Erick?

~ David Smiley


Erick Erickson wrote:
> 
> Sorry if this double-posts, but gmail is being wonky...
> 
> I saw a situation recently where query strings with isolated
> meta-characters were going to edismax with unfortunate results. For
> instance:
> 
> blah blah * blah blah
> 
> or
> 
> blah blah ~ blah blah
> 
> edismax happily spreads these across all of the fields leading
> to...er...interesting behavior, and 5+ minute query responses.
> 
> Should we consider dis-allowing any of these? Or is the best response
> that they should have Solr locked down and take care of this at the
> app level if they care?
> 
> I suspect the right answer is the latter but thought I'd throw it out
> for discussion.
> 
> Erick
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


-
 Author: https://www.packtpub.com/solr-1-4-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/edismax-and-wildcards-tp3269153p3269918.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Welcome Erick Erickson as Lucene/Solr committer

[David Smiley (@MITRE.org)]

Congrats Erick! I've noticed you on the mailing list for a long time and
you've offered many people good advise.

~ David Smiley

-
 Author: https://www.packtpub.com/solr-1-4-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Welcome-Erick-Erickson-as-Lucene-Solr-committer-tp3012429p3013723.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [VOTE] Release Lucene/Solr 3.2.0

[David Smiley (@MITRE.org)]

You're right; it shouldn't be shoved in at the last second -- I didn't mean
to imply that. It should be committed and then we'll give it a comfortable
amount of time.  When that time is up, and if v3.2 waits for it, then 3.2
will probably be at about the 3-month mark since the last release -- in my
view (and Grant's) the ideal suite-spot for a release window.

Releasing too fast / too infrequent aside, I think a X.X release should have
a notable feature (or a huge performance improvement), and 3.2 doesn't
without result grouping, IMO. It's got plumbing and bug fixes.

~ David Smiley

-
 Author: https://www.packtpub.com/solr-1-4-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/VOTE-Release-Lucene-Solr-3-2-0-tp2993434p2997968.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [VOTE] Release Lucene/Solr 3.2.0

[David Smiley (@MITRE.org)]

Cool idea!  I had the same thought -- an automated reminder every 2.5 months
or so.

-
 Author: https://www.packtpub.com/solr-1-4-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/VOTE-Release-Lucene-Solr-3-2-0-tp2993434p2997954.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [VOTE] Release Lucene/Solr 3.2.0

[David Smiley (@MITRE.org)]

The basis of my preference to start the 3.2 release was the existence of some
cool meaningful feature in it over the previous release.  Since Result
Grouping isn't going to make it, I am not in favor of releasing 3.2. Why not
wait till we're happy with it being committed?  I've toyed with it a week
ago and was pleased.

Here are the list of LUCENE and SOLR JIRA issues of type improvement or
new-feature with a resolution of fixed with a priority greater than "minor"
and a fix-version for 3.2:
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+in+%28SOLR%2C+LUCENE%29+AND+issuetype+in+%28%22New+Feature%22%2C+Improvement%29+AND+resolution+%3D+Fixed+AND+fixVersion+%3D+%223.2%22+and+priority+%3E+minor
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+in+%28SOLR%2C+LUCENE%29+AND+issuetype+in+%28%22New+Feature%22%2C+Improvement%29+AND+resolution+%3D+Fixed+AND+fixVersion+%3D+%223.2%22+and+priority+%3E+minor
 

~ David Smiley

-
 Author: https://www.packtpub.com/solr-1-4-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/VOTE-Release-Lucene-Solr-3-2-0-tp2993434p2996144.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [VOTE] Release Lucene/Solr 3.2.0

[David Smiley (@MITRE.org)]

Clearly a year+ is too long to release, and thankfully it appears that's in
the past for Lucene/Solr.  But on the other extreme, one can release too
quickly as well, of course.  There is overhead to performing the release
itself.  Consequently there should be enough "goodness" in the release to
make it feel worthwhile. And because we value stability and robustness in
Lucene/Solr, changed code should have *some* amount of time to be
potentially used and tested further.  And there's impact on the user
community. If a release occurred too frequently then there might be very
little meaningful improvements in the release. I believe it is Hudson (now
Jenkins) that followed that extreme of I think releasing every week or so.
It's so frequent that as an admin of such a server where I work, I don't
even care to look at what's new in the releases because there are too many
of them--I've become apathetic when I was initially excited to use it. So
hopefully with each release there's something truly cool to tell others
about in Lucene/Solr.  

Gauging these factors is of course very subjective.  Personally, I think 3
months is just right, 1 or less is too fast. Given that v3.1 was released 2
months ago and there are some truly cool features like Result Grouping in
Solr to announce in 3.2. I'm in favor of a release.

~ David Smiley

-
 Author: https://www.packtpub.com/solr-1-4-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/VOTE-Release-Lucene-Solr-3-2-0-tp2993434p2995419.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: FST and FieldCache?

[David Smiley (@MITRE.org)]

Wow, 17 replies to my email overnight! This is clearly an interesting topic
to folks.

Hi Dawid.
Sadly, I won't be at Lucene Revolution next week. That's where all the cool
kids will be; I'll be home and be square. I made it to O'Reilly Strata in
February (a great conference) and I'll be presenting at Basis's "Open Source
Search Conference" (government customer focused) mid-June.  I've used up my
conference budget for this fiscal year.

Yes, the use-case here is a unique integer reference to a String that can be
looked up fairly quickly, whereas the set of all strings are in a compressed
data structure that won't change after its built. A bonus benefit would be
that this integer is a sortable substitute for the String.  Your observation
of this integer being a perfect-hash is astute.

I wonder if Lucene could store this FST on-disk for the bytes in a segment
instead of what it's doing now? Read-time construction would be super-fast,
though for multi-segment indexes, I suppose they'd need to be merged.

I expect that this use-case would be particularly useful for cases when you
know that the set of strings tends to have a great deal of prefixes in
common, such as when EdgeNGramming (applications: query-complete,
hierarchical faceting, prefix/tree based geospatial indexing).

~ David Smiley


Dawid Weiss wrote:
> 
> Hi David,
> 
>> but with less memory.  As I understand it, FSTs are a highly compressed
>> representation of a set of Strings (among other possibilities).  The
> 
> Yep. Not only, but this is one of the use cases. Will you be at Lucene
> Revolution next week? I'll be talking about it there.
> 
>> representation of a set of Strings (among other possibilities).  The
>> fieldCache would need to point to an FST entry (an "arc"?) using
>> something
>> small, say an integer.  Is there a way to point to an FST entry with an
>> integer, and then somehow with relative efficiency construct the String
>> from
>> the arcs to get there?
> 
> Correct me if my understanding is wrong: you'd like to assign a unique
> integer to each String and then retrieve it by this integer (something
> like a
> Map)? This would be something called perfect
> hashing
> and this can be done on top of an automaton (fairly easily). I assume
> the data structure is immutable once constructed and does not change
> too often, right?
> 
> Dawid
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

-
 Author: https://www.packtpub.com/solr-1-4-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/FST-and-FieldCache-tp2960030p2961954.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: FST and FieldCache?

[David Smiley (@MITRE.org)]

Michael McCandless-2 wrote:
> 
> I think a more productive area of exploration (to reduce RAM usage)
> would be to make a StringFieldComparator that doesn't need full access
> to all terms data, ie, operates per segment yet only does a "few" ord
> lookups when merging the results across segments.  If "few" is small
> enough we can just use us the seek-by-ord from the terms dict to do
> them.  This would be a huge RAM reduction because we could then sort
> by string fields (eg "title" field) without needing all term bytes
> randomly accessible.
> 
> Mike
> 

Yes!  I don't want to put all my titles into RAM just to sort documents by
them when I know Lucene has indexed the titles in sorted order on disk
already.  Of course the devil is in the details.

~ David Smiley

-
 Author: https://www.packtpub.com/solr-1-4-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/FST-and-FieldCache-tp2960030p2961687.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

FST and FieldCache?

[David Smiley (@MITRE.org)]

I've been pondering how to reduce the size of FieldCache entries when there
are a large number of Strings. I'd like to facet on such a field with Solr
but with less memory.  As I understand it, FSTs are a highly compressed
representation of a set of Strings (among other possibilities).  The
fieldCache would need to point to an FST entry (an "arc"?) using something
small, say an integer.  Is there a way to point to an FST entry with an
integer, and then somehow with relative efficiency construct the String from
the arcs to get there?

~ David Smiley

-
 Author: https://www.packtpub.com/solr-1-4-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/FST-and-FieldCache-tp2960030p2960030.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

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

[David Smiley (@MITRE.org)]

I don't think "Next" is necessarily dangerous; if used then "3.2", shouldn't
exist until it's time to release. Having both is dangerous. But sure, I'm in
favor of removing "Next". A committer would have to adjudicate all issues
and substitute either 3.2 or 4.0.  Speaking of which, I think simply
assigning a fix-version for "3.2" implies that it will be for any future
release (including 4.0) and so I don't see there's a point in assigning both
of these fix-versions.  There are rare exceptions to this and I am aware of
course that our dual-development branches implies having to make two
commits.

RE v1.5, fortunately, most of the issues are already assigned a suitable
fix-version other than 1.5 so those can be ignored. Once the few remainder
are addressed, v1.5 can be deleted.
RE Next, Any issue with a resolution status of "Fixed" should be re-assigned
a suitable fix-version if it doesn't have any.  There are very few of these
two worry about. Those without a resolution status should probably just be
assigned to 3.2 -- so yes I agree that's what we should do.  Then "Next" can
be deleted.

~ David Smiley


Michael McCandless-2 wrote:
> 
> On Fri, Apr 29, 2011 at 12:12 AM, David Smiley (@MITRE.org)
> <dsmi...@mitre.org> wrote:
> 
>> (Comments on SOLR-2191 between Mark & I were starting to get off-topic
>> with
>> respect to the issue so I am continuing the conversation here)
>>
>> A lot of JIRA issues seem to fall off the radar, IMO. I'm talking about
>> issues that have patches and are basically ready to go.  There are
>> multiple
>> ways to address this but at the moment I am going to just bring up one.
>> Looking at the versions in JIRA one can assign an issue to
>> https://issues.apache.org/jira/browse/SOLR#selectedTab=com.atlassian.jira.plugin.system.project%3Aversions-panel
>> I see the version named "Next", with this description: "Placeholder for
>> commiters to track issues that are not ready to commit, but seem close
>> enough to being ready to warrant focus before the next feature release".
>> This version and what it implies is a common pattern in use of JIRA that
>> I
>> too use for projects I manage for my employer. It appears that for the
>> 3.1
>> release, nobody looked through the issues assigned to "Next", and
>> consequently, some issues like SOLR-2191 were forgotten despite being
>> ready
>> to go.  Looking through the wiki I see information on how to do a release
>> http://wiki.apache.org/solr/HowToRelease and release suggestions but no
>> information on what to do in advance of a release.  I also don't see any
>> administrative tasks on managing the "Next" version in JIRA.  So I think
>> either the "Next" version should be used effectively, or if that isn't
>> going
>> to happen then delete this version.
> 
> I agree Next is dangerous!
> 
> It'd be nice if Jira could auto-magically treat Next as whatever
> release really is "next".  EG, say we all agree 3.2 is our next
> release, then ideally Jira would treat all Next issues as if they were
> marked with 3.2.
> 
> But... lacking that, maybe we really shouldn't use Next at all, and
> just use 3.2?  Having to step through these issues and move them to
> the next release on releasing is also healthy, ie, it's good that we
> see/review them, think about why we didn't get it done on the current
> release, etc.
> 
>> On a related note, I don't know what to make of the "1.5" version, nor
>> what
>> to make of issues marked as Closed for "Next".  Some house cleaning is in
>> order.
> 
> We should clean these up.  Should we just roll them over to 3.2?
> 
> Mike
> 
> http://blog.mikemccandless.com
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

- Author: https://www.packtpub.com/solr-1-4-enterprise-search-server/book--
View this message in context: 
http://lucene.472066.n3.nabble.com/Re-jira-issues-falling-off-the-radar-Next-JIRA-version-tp2886427p2886427.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

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

[David Smiley (@MITRE.org)]

(Comments on SOLR-2191 between Mark & I were starting to get off-topic with
respect to the issue so I am continuing the conversation here)

A lot of JIRA issues seem to fall off the radar, IMO. I'm talking about
issues that have patches and are basically ready to go.  There are multiple
ways to address this but at the moment I am going to just bring up one.
Looking at the versions in JIRA one can assign an issue to
https://issues.apache.org/jira/browse/SOLR#selectedTab=com.atlassian.jira.plugin.system.project%3Aversions-panel
I see the version named "Next", with this description: "Placeholder for
commiters to track issues that are not ready to commit, but seem close
enough to being ready to warrant focus before the next feature release".
This version and what it implies is a common pattern in use of JIRA that I
too use for projects I manage for my employer. It appears that for the 3.1
release, nobody looked through the issues assigned to "Next", and
consequently, some issues like SOLR-2191 were forgotten despite being ready
to go.  Looking through the wiki I see information on how to do a release
http://wiki.apache.org/solr/HowToRelease and release suggestions but no
information on what to do in advance of a release.  I also don't see any
administrative tasks on managing the "Next" version in JIRA.  So I think
either the "Next" version should be used effectively, or if that isn't going
to happen then delete this version.

On a related note, I don't know what to make of the "1.5" version, nor what
to make of issues marked as Closed for "Next".  Some house cleaning is in
order.

Thoughts?

~ David Smiley
- Author: https://www.packtpub.com/solr-1-4-enterprise-search-server/book--
View this message in context: 
http://lucene.472066.n3.nabble.com/jira-Created-SOLR-2191-Change-SolrException-cstrs-that-take-Throwable-to-default-to-alreadyLogged-fae-tp1763003p2878021.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Lucene & Solr a one way street?

[David Smiley (@MITRE.org)]

It's good to see this discussion finally happen.  Some things are in Solr
(e.g. faceting, function queries, Yonik's recent join patch, ...) that
probably belong in Lucene.  As someone contributing functionality to
Lucene/Solr in SOLR-2155 (Geospatial search via geohash prefix techniques),
anecdotally I find it most convenient for the code to span both Lucene and
Solr, particularly Solr on the testing side.  (Of course each patch is
different but this is my experience)  The testing infrastructure on the Solr
side is excellent.  As I look to implement sorting it's going to be
difficult to have a non-Solr user take the code since the sorting capability
is wrapped up in Solr concepts like function queries.

~ David Smiley

-
 Author: https://www.packtpub.com/solr-1-4-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/Lucene-Solr-a-one-way-street-tp2672821p2674116.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [VOTE] Lucene and Solr 3.1 release candidate

[David Smiley (@MITRE.org)]

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

-
 Author: https://www.packtpub.com/solr-1-4-enterprise-search-server/book
--
View this message in context: 
http://lucene.472066.n3.nabble.com/VOTE-Lucene-and-Solr-3-1-release-candidate-tp2645100p2646445.html
Sent from the Solr - Dev mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org