Re: Math Processing for Solr

[Ryan McKinley]

(perhaps more appropriate on solr-user@)

It sounds like you want to make a MathML filter?  Check out the
analyzer packages...

http://wiki.apache.org/solr/AnalyzersTokenizersTokenFilters

simple example:
https://svn.apache.org/repos/asf/lucene/dev/trunk/solr/src/java/org/apache/solr/analysis/LengthFilterFactory.java

ryan


2010/4/14  :
> Hello everybody,
>
> I'm new to all this so I hope this isn't too noob a question and that it
> isn't very inappropriate here.
>
> I'm currently working on a indexing/searching application based on Apache
> Lucene core, that can process mathematical formulae in MathML format
> (which is extension to XML) and store it in the index for searching. No
> troubles here, since I'm making everything above Lucene.
>
> But I started to think it would be nice to write this mathematical
> extension so it could be incorporated into Solr as easy as possible in the
> future. The thing is I looked into Solr's sources and I'm all confused to
> be honest and don't know which way to do this.
>
> Basic workflow of the whole math processing would be:
> Check the input document for any math->if found, mathematical unit needs
> to process it and produce many string-represented formulae with different
> boosts->put these into index not tokenized furthermore.
>
> That's about it.
> Any ideas? Any help will be appreciated.
>
> Thank you
>
> Martin
>
>

Re: Solr & Java 1.6 ... was: Re: [jira] Commented: (SOLR-1873) Commit Solr Cloud to trunk

[Ryan McKinley]

I'm fine with 1.6 as a min requirement...  but i imagine others have
different opinions :)


On Wed, Apr 14, 2010 at 2:53 PM, Yonik Seeley
 wrote:
> Yes, it requires that Solr in general is compiled with Java6.  We
> should make our lives easier and make Java6 a Solr requirement.
> Zookeeper requires Java6, and we also want Java6 for some of the
> scripting capabilities.
>
> -Yonik
> Apache Lucene Eurocon 2010
> 18-21 May 2010 | Prague
>
>
> On Wed, Apr 14, 2010 at 2:35 PM, Chris Hostetter
>  wrote:
>>
>> I haven't been following the Cloud stuff very closely, can someone clarify
>> what exactly the situation is w/Solr Cloud and Java 1.6.
>>
>> Will merging the cloud changes to trunk require that core pieces of Solr
>> be compiled/run with Java 1.6 (ie: a change to our minimum operating
>> requirements) or will it just require that people wanting cloud
>> management features use a 1.6 JVM and include a new solr contrib and
>> appropriate config options at run time (and this contrib is the only thing
>> that needs to be compiled with 1.6) ?
>>
>> As far as hudson and the build system goes ... there's certainly no reason
>> we can't have more then one setup ... one build using JDK 1.5 (with the
>> build.xml files detecting the JDK version and vocally not building the
>> code that can't be compiled (either just the contrib, or all of solr) and
>> a seperate build using JDK 1.6 that builds and test everything.
>>
>> (having this setup in general would be handy if/when other lucene contribs
>> start wanting to incorporate Java 1.6 features)
>>
>>
>> : bq. As I wrap up the remaining work here, one issue looms: We are going
>> : to need to move Hudson to Java 6 before this can be committed.
>> :
>> : In most respects, I think that would be a positive anyway.  Java6 is now
>> : the primary production deployment platform for new projects (and it's
>> : new projects that will be using new lucene and/or solr).  With respect
>> : to keeping Lucene Java5 compatible, we can always run the tests with
>> : Java5 before commits (that's what I did in the past when Lucene was on
>> : Java1.4)
>>
>>
>>
>> -Hoss
>>
>>
>

Re: Document level security in Apache Solr

[Ryan McKinley]

Hi Anders-

see comments below...

>
> Two weeks ago I created a JIRA issue (
> https://issues.apache.org/jira/browse/SOLR-1834) involving document level
> security in Apache Solr and submitted a patch containing a search component
> that can be seen as a starting point for making Solr handle document level
> security. I believe that document security is an essential part of an
> enterprise search engine and I hope that this contribution can start a
> discussion about how this should be handled in Solr (possibly in conjunction
> with the Lucene Connector Framework).
>

Thanks for posting the code -- a quick pass it looks good.  I agree
some cordination with Lucene Connectors will make sense.

On the patch, it looks good, but to get into the the dist, it will
probably need some sort of tests.  I'm not sure how that would work
with windows authentication (I don't' know much about it, but it has
been on my long term TODO list for a while!)  Perhaps we could have
tests that would run on systems that have somethign to test agains,
but not fail when running on linux (or something)


> As this contribution shows I would like to help to develop the security
> capabilities of Solr together with the community because I believe that it
> will improve Solr’s appeal to large enterprises. Moreover I think that most
> of us believe that a transparent security system will in the end give rise
> to the best security.
>

agree  -- the more people to poke holes, the better


> I hope some of you can take the time to look at the patch, try it out and
> think about:
>
> 1)      1. Should this be a contrib module in Solr? (And if so, what needs
> to be done to contribute it?)
>

I think a contrib module makes sense.  For things to move forward, a
committer needs to step up to the plate.  I would love to, but don't
have much time soon.  To make it easier for people to feel comfortable
with it, tests and doc help lots.


> 2)      2. Should document level security be a core feature in Solr? (And if
> so, what is the best way to integrate it into Solr?)

I'm not quite sure what you mean by 'core' -- I think it makes sense
to live as a contrib for a while and see how things develop.


>
> 3)      3. How can this integrate with connectors like the Lucene Connector
> Framework? I.e. how do you create a uniform way to talk about Access Control
> Lists (http://en.wikipedia.org/wiki/Access_control_list).
>

good question!  That would be really powerful.


>
>
> P.s (for the nerdy)
>
> I have some ideas about putting the security deeper into Solr, perhaps by
> creating a secure SolrIndexReader and a secure SolrIndexSearcher that are
> fed user credentials from a search component. What do you think about this?
>

What are you thinking here?  To me, it seems like the index would need
to contain all data and a SearchComponet would take user credentials
and augment the query (group:[a b c] or whatever)

The advantage of keeping the same IndexSearch across all users is that
it can share a cache where appropriate.


> As I understand it, currently it’s possible to declare your own
> SolrIndexReader but not your own SolrIndexSearcher.
>

not sure on this...


ryan

Re: Branding Solr+Lucene

[Ryan McKinley]

I'm confused... what is the need for a new name?  The only place where
there is a conflict is in the top level svn tree...

What about something general like:
https://svn.apache.org/repos/asf/lucene/dev
or
https://svn.apache.org/repos/asf/lucene/project

ryan


On Mon, Mar 22, 2010 at 2:02 PM, Steven A Rowe  wrote:
> Now that Solr and Lucene live in the same space, there has been an on-going 
> debate about what to call the merged entity.
>
> The names being mulled at this point include (variously sized) snippets of 
> both Lucene's and Solr's names, and include LuSolr, Solcene, etc. (my current 
> personal favorites along these lines: Sorlusr :) ).
>
> My guess is that Lucene partisans would like to see Solr just become a 
> product (along with the Lucene java library) of the Lucene project.  Judging 
> from suggestions coming from Solr partisans, though, I don't think this will 
> fly.
>
> So I think an entirely new name is needed for the merged project.  Lucene and 
> Solr would remain the product names of this newly named merged project.
>
> Along these lines, search.apache.org has been brought up a couple of times 
> recently on the #lucene IRC channel.  However (with all due respect to 
> what-happens-on-#lucene-stays-on-#lucene (TM) ), Grant wrote in response to 
> one of these suggestions this morning:
>
>   prob. is "Search" is not a brand
>   ASF likes names
>
> So in the spirit of a real name (i.e., an abstract symbol), I propose 
> "Srrrch" (riffing off of "Riot Grrrls" and Solr's penchant for vowel 
> droppings)  Okay, not really.
>
> I do have one idea, though: thinking about the icons for Lucene (looks to me 
> like the font used on 50's automobile brand logos) and Solr (a sun): car+sun 
> => convertible => "Ragtop".  Fun, short, abstract, apolitical.  Solr's and 
> Lucene's icons could be easily embedded in a Ragtop logo.
>
> Steve
>
>
> -
> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: java-dev-h...@lucene.apache.org
>
>

Re: Mailing List merge

[Ryan McKinley]

Logistically, how would this work?

would d...@lucene.apache.org be an alias for java-dev and solr-dev? or
a whole new list?

Would people need to subscribe to it, or would you already be on the
list if you were on java/solr dev?  If we are on both lists, do we get
two copies of every message?


On Mon, Mar 22, 2010 at 11:44 AM, Grant Ingersoll  wrote:
> Shall we merge the dev mailing lists?  This should reduce the cross-posting 
> and can be completely automated (other than you may have to update your 
> client-side filters) and was part of the plan to merge dev efforts.
>
> I'd propose it be called lucene-solr-...@l.a.o.  I can put in an issue for 
> infra@ to do it.
>
> -Grant
> -
> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: java-dev-h...@lucene.apache.org
>
>

Re: Mailing List merge

[Ryan McKinley]

why not just "d...@lucene.apache.org"?



On Mon, Mar 22, 2010 at 11:44 AM, Grant Ingersoll  wrote:
> Shall we merge the dev mailing lists?  This should reduce the cross-posting 
> and can be completely automated (other than you may have to update your 
> client-side filters) and was part of the plan to merge dev efforts.
>
> I'd propose it be called lucene-solr-...@l.a.o.  I can put in an issue for 
> infra@ to do it.
>
> -Grant
> -
> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: java-dev-h...@lucene.apache.org
>
>

Re: rough outline of where Solr's going

[Ryan McKinley]

>
> I don't see a compelling reason to go to 3.1.  It is going to be very 
> confusing for users ("when did 3.0 come out?  Did I miss it?")   At least 
> when MS Word jumped from 2.0 to 6.0 it wasn't to a "minor" version (i.e. 
> 6.1).  2.0 seems reasonable, as does 1.5.  Although 2.0 would be a good 
> reason to get rid of deprecations.
>

I agree.  2.0 or 1.5 makes the most sense.

(In the past I suggested we may not be at 2.0 yet... but with all the
internal re-jiggering, I now think 2.0 would be best).

Locking the solr major number to lucene major number does not make any
sense to me.  Say there were a major change to solr (for argument
sake, perhaps it gets in bed with spring), but there is no major
change in lucene...  then what?

Re: multiple cores w/same name in solr.xml ???

[Ryan McKinley]

>
> Is there any reason why CoreContainer shouldn't throw an exception if
> solr.xml declares a core w/o a name, or two cores with the same name?

This makes sense.  I think WAY WAY back (in a patch), cores could be
initialized by index, but that became moot with the CoreContainer
stuff.

ryan

Re: svn commit: r898393 [1/3] - in /lucene/solr/branches/cloud: ./ client/ruby/solr-ruby/solr/conf/ client/ruby/solr-ruby/test/conf/ contrib/clustering/ contrib/clustering/lib/ contrib/clustering/src/

[Ryan McKinley]

On Jan 12, 2010, at 10:59 AM, markrmil...@apache.org wrote:


Author: markrmiller
Date: Tue Jan 12 15:59:01 2010
New Revision: 898393

URL: http://svn.apache.org/viewvc?rev=898393&view=rev
Log:
merge up to r898346



dooh, sorry mark -- hope that was not too difficult.

thanks
ryan

Re: LucidWorks for Solr Reference Guide on front page?

[Ryan McKinley]

On Jan 12, 2010, at 5:45 AM, Erik Hatcher wrote:


Hey gang,

I'd like to put an image and link to our LucidWorks for Solr  
Certified Distro Reference Guide on the Solr front page, and  
wondering if there were any objections.


To toss out my only objection with my Apache hat on (yes, I'm really  
wearing it!), the reference guide isn't strictly about *Apache*  
Solr, it's about our distro of it.  So there is just a little bit  
more than in the distro (like kstem, tomcat).  But then again, the  
Packt book* has more than what's in Solr 1.4 too (localsolr, field  
collapsing).


Here's a link to our reference guide, that includes the image I'd  
use too:



If there are no objections, I'll add it sometime this week.


+1, more doc is better then less!

ryan

[jira] Commented: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there

[Ryan McKinley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12799059#action_12799059
 ] 

Ryan McKinley commented on SOLR-1602:
-

I made a few changes to /trunk, but we are still missing:
1. error messages
2. CHANGES.txt 
3. FQN seems to be the only thing that worked easily.  Need to look into it 
more to see what we can do with SolrResourceLoader

Now that the main changes are in, attaching patces is useful :)

> Refactor SOLR package structure to include o.a.solr.response and move 
> QueryResponseWriters in there
> ---
>
> Key: SOLR-1602
> URL: https://issues.apache.org/jira/browse/SOLR-1602
> Project: Solr
>  Issue Type: Improvement
>  Components: Response Writers
>Affects Versions: 1.2, 1.3, 1.4
> Environment: independent of environment (code structure)
>Reporter: Chris A. Mattmann
>Assignee: Ryan McKinley
> Fix For: 1.5
>
> Attachments: SOLR-1602.Mattmann.112509.patch.txt, 
> SOLR-1602.Mattmann.112509_02.patch.txt, upgrade_solr_config
>
>
> Currently all o.a.solr.request.QueryResponseWriter implementations are 
> curiously located in the o.a.solr.request package. Not only is this package 
> getting big (30+ classes), a lot of them are misplaced. There should be a 
> first-class o.a.solr.response package, and the response related classes 
> should be given a home there. Patch forthcoming.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there

[Ryan McKinley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan McKinley reassigned SOLR-1602:
---

Assignee: Ryan McKinley  (was: Noble Paul)

> Refactor SOLR package structure to include o.a.solr.response and move 
> QueryResponseWriters in there
> ---
>
> Key: SOLR-1602
> URL: https://issues.apache.org/jira/browse/SOLR-1602
> Project: Solr
>  Issue Type: Improvement
>  Components: Response Writers
>Affects Versions: 1.2, 1.3, 1.4
> Environment: independent of environment (code structure)
>Reporter: Chris A. Mattmann
>Assignee: Ryan McKinley
> Fix For: 1.5
>
> Attachments: SOLR-1602.Mattmann.112509.patch.txt, 
> SOLR-1602.Mattmann.112509_02.patch.txt, upgrade_solr_config
>
>
> Currently all o.a.solr.request.QueryResponseWriter implementations are 
> curiously located in the o.a.solr.request package. Not only is this package 
> getting big (30+ classes), a lot of them are misplaced. There should be a 
> first-class o.a.solr.response package, and the response related classes 
> should be given a home there. Patch forthcoming.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1715) Externally Generated Filters

[Ryan McKinley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12798797#action_12798797
 ] 

Ryan McKinley commented on SOLR-1715:
-

this would also be a good way to 'punt' complex geographic queries to some 
other system.  

> Externally Generated Filters
> 
>
> Key: SOLR-1715
> URL: https://issues.apache.org/jira/browse/SOLR-1715
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Reporter: Grant Ingersoll
>Priority: Minor
> Fix For: 1.6, 2.0
>
>
> I'd like to have a way of loading document filters from externally generated 
> sources.  For instance, I may have run a clustering task over my corpus and 
> the results may be stored in HDFS (Hadoop).  A given cluster will have a 
> centroid and a bunch of points that are in the cluster.  The points are 
> labeled by doc id (the Solr doc id) from the index.  
> Another example is I may have an external security system that can provide 
> info on which documents are available to a user.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Race condition in org/apache/solr/client/solrj/impl/StreamingUpdateSolrServer

[Ryan McKinley]

can  you submit a patch to JIRA?


On Jan 7, 2010, at 10:23 AM, Attila Babo wrote:


While inserting a large pile of documents using
StreamingUpdateSolrServer I've found a race condition as all Runner
instances stopped while the blocking queue was full. The attached
patch solves the problem, to minify it all indentation has been
removed.

Index: src/solrj/org/apache/solr/client/solrj/impl/ 
StreamingUpdateSolrServer.java

===
--- src/solrj/org/apache/solr/client/solrj/impl/ 
StreamingUpdateSolrServer.java	(revision

888167)
+++ src/solrj/org/apache/solr/client/solrj/impl/ 
StreamingUpdateSolrServer.java	(working

copy)
@@ -82,6 +82,7 @@
  log.info( "starting runner: {}" , this );
  PostMethod method = null;
  try {
+do {
RequestEntity request = new RequestEntity() {
  // we don't know the length
  public long getContentLength() { return -1; }
@@ -142,6 +143,7 @@
  msg.append( "request: "+method.getURI() );
  handleError( new Exception( msg.toString() ) );
}
+}  while( ! queue.isEmpty());
  }
  catch (Throwable e) {
handleError( e );
@@ -149,6 +151,7 @@
  finally {
try {
  // make sure to release the connection
+  if(method != null)
  method.releaseConnection();
}
catch( Exception ex ){}
@@ -195,11 +198,11 @@

  queue.put( req );

+synchronized( runners ) {
  if( runners.isEmpty()
|| (queue.remainingCapacity() < queue.size()
 && runners.size() < threadCount) )
  {
-synchronized( runners ) {
  Runner r = new Runner();
  scheduler.execute( r );
  runners.add( r );

===

This patch has been tested with millions of document inserted to Solr,
before that I was unable to inject all of our documents as the
following scenario happened. We have a BlockingQueue called runners to
handle requests, at one point the queue was emptied by the Runner
threads, they all stopped processing new items but sent the collected
items to Solr. Solr was busy so that toke a long time, during that the
client filled the queue again. As all worker threads were instantiated
there were no way to create new Runners to handle the queue so it was
growing to upper limit. When the next item was about to put into the
queue it was blocked and the race condition just happened.

Patch 1, 2:
Inside the Runner.run method I've added a do while loop to prevent the
Runner to quit while there are new requests, this handles the problem
of new requests added while Runner is sending the previous batch.

Patch 3
Validity check of method variable is not strictly necessary, just a
code clean up.

Patch 4
The last part of the patch is to move synchronized outside of
conditional to avoid a situation where runners change while evaluating
it.

Your comments and critique are welcome!

Attila

[jira] Commented: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there

[Ryan McKinley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12797678#action_12797678
 ] 

Ryan McKinley commented on SOLR-1602:
-

Nobel, this issue is assigned to you?  Do you want to take care of it?  If not 
I can...

Patches won't work well since it will be a few steps in svn to make sure the 
history is maintained:
1. svn move the files to a new location, update references etc
2. commit
3. add stub files in the location where the old files were
4. commit

> Refactor SOLR package structure to include o.a.solr.response and move 
> QueryResponseWriters in there
> ---
>
> Key: SOLR-1602
> URL: https://issues.apache.org/jira/browse/SOLR-1602
> Project: Solr
>  Issue Type: Improvement
>  Components: Response Writers
>Affects Versions: 1.2, 1.3, 1.4
> Environment: independent of environment (code structure)
>Reporter: Chris A. Mattmann
>Assignee: Noble Paul
> Fix For: 1.5
>
> Attachments: SOLR-1602.Mattmann.112509.patch.txt, 
> SOLR-1602.Mattmann.112509_02.patch.txt, upgrade_solr_config
>
>
> Currently all o.a.solr.request.QueryResponseWriter implementations are 
> curiously located in the o.a.solr.request package. Not only is this package 
> getting big (30+ classes), a lot of them are misplaced. There should be a 
> first-class o.a.solr.response package, and the response related classes 
> should be given a home there. Patch forthcoming.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there

[Ryan McKinley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12797677#action_12797677
 ] 

Ryan McKinley commented on SOLR-1602:
-

| .Besides which: even if it's just an "example" it would be pretty shitty to 
break that example in the very next release.

Agreed -- we will make sure old FQNs work (until the next major release), but 
moving forward, we should remove FQN from schema.xml so this is less of an 
issue in the future.



> Refactor SOLR package structure to include o.a.solr.response and move 
> QueryResponseWriters in there
> ---
>
> Key: SOLR-1602
> URL: https://issues.apache.org/jira/browse/SOLR-1602
> Project: Solr
>  Issue Type: Improvement
>  Components: Response Writers
>Affects Versions: 1.2, 1.3, 1.4
> Environment: independent of environment (code structure)
>Reporter: Chris A. Mattmann
>Assignee: Noble Paul
> Fix For: 1.5
>
> Attachments: SOLR-1602.Mattmann.112509.patch.txt, 
> SOLR-1602.Mattmann.112509_02.patch.txt, upgrade_solr_config
>
>
> Currently all o.a.solr.request.QueryResponseWriter implementations are 
> curiously located in the o.a.solr.request package. Not only is this package 
> getting big (30+ classes), a lot of them are misplaced. There should be a 
> first-class o.a.solr.response package, and the response related classes 
> should be given a home there. Patch forthcoming.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there

[Ryan McKinley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12797227#action_12797227
 ] 

Ryan McKinley commented on SOLR-1602:
-

Hey Chris-

Don't worry about putting up a patch... the real work is just svn move and that 
does not work well with patches.

Lets wait a few days and see if there are no objections, I will do the 
refactoring (and replacing) on the repos that would get committed.

ryan

> Refactor SOLR package structure to include o.a.solr.response and move 
> QueryResponseWriters in there
> ---
>
> Key: SOLR-1602
> URL: https://issues.apache.org/jira/browse/SOLR-1602
> Project: Solr
>  Issue Type: Improvement
>  Components: Response Writers
>Affects Versions: 1.2, 1.3, 1.4
> Environment: independent of environment (code structure)
>Reporter: Chris A. Mattmann
>Assignee: Noble Paul
> Fix For: 1.5
>
> Attachments: SOLR-1602.Mattmann.112509.patch.txt, 
> SOLR-1602.Mattmann.112509_02.patch.txt, upgrade_solr_config
>
>
> Currently all o.a.solr.request.QueryResponseWriter implementations are 
> curiously located in the o.a.solr.request package. Not only is this package 
> getting big (30+ classes), a lot of them are misplaced. There should be a 
> first-class o.a.solr.response package, and the response related classes 
> should be given a home there. Patch forthcoming.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1568) Implement Spatial Filter

[Ryan McKinley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12796352#action_12796352
 ] 

Ryan McKinley commented on SOLR-1568:
-

{quote}
could be written as 
{code}
&fq={!sfilt f=location}
&p=49,-77
&d=1000
{code}
{quote}

Jeez -- I had no idea...  then I think (most?) cases are taken care of...

With this, a handler could be defined with the default param: 'fq={!sfilt 
f=location}' and the 'end user' could simply call:
  &p=49,-77&d=1000
never needing to grock the local-params/function syntax.


> Implement Spatial Filter
> 
>
> Key: SOLR-1568
> URL: https://issues.apache.org/jira/browse/SOLR-1568
> Project: Solr
>  Issue Type: New Feature
>Reporter: Grant Ingersoll
>Assignee: Grant Ingersoll
>Priority: Minor
> Fix For: 1.5
>
> Attachments: CartesianTierQParserPlugin.java
>
>
> Given an index with spatial information (either as a geohash, 
> SpatialTileField (see SOLR-1586) or just two lat/lon pairs), we should be 
> able to pass in a filter query that takes in the field name, lat, lon and 
> distance and produces an appropriate Filter (i.e. one that is aware of the 
> underlying field type for use by Solr. 
> The interface _could_ look like:
> {code}
> &fq={!sfilt dist=20}location:49.32,-79.0
> {code}
> or it could be:
> {code}
> &fq={!sfilt lat=49.32 lat=-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt p=49.32,-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt lat=49.32,-79.0 fl=lat,lon dist=20}
> {code}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there

[Ryan McKinley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12796285#action_12796285
 ] 

Ryan McKinley commented on SOLR-1602:
-

In an effort to get some resolution here...

There are only three options:
A. Leave it as is
B. Refactor *with* deprecations
--C. Refactor without deprecations--

C is out, so A and B are the only options worth discussing.

The advantage of B is that the package:
 o.a.s.response would be clean and organized
(but o.a.s.request would still have a bunch of deprecated files)

The arguments for A amount to: "things are fine as they are", or "the confusion 
of changing is not worth whatever slight gain we would get"

The strong resistance is to 'C', I suspect wider ambivalence towards 'B'




> Refactor SOLR package structure to include o.a.solr.response and move 
> QueryResponseWriters in there
> ---
>
> Key: SOLR-1602
> URL: https://issues.apache.org/jira/browse/SOLR-1602
> Project: Solr
>  Issue Type: Improvement
>  Components: Response Writers
>Affects Versions: 1.2, 1.3, 1.4
> Environment: independent of environment (code structure)
>Reporter: Chris A. Mattmann
>Assignee: Noble Paul
> Fix For: 1.5
>
> Attachments: SOLR-1602.Mattmann.112509.patch.txt, 
> SOLR-1602.Mattmann.112509_02.patch.txt, upgrade_solr_config
>
>
> Currently all o.a.solr.request.QueryResponseWriter implementations are 
> curiously located in the o.a.solr.request package. Not only is this package 
> getting big (30+ classes), a lot of them are misplaced. There should be a 
> first-class o.a.solr.response package, and the response related classes 
> should be given a home there. Patch forthcoming.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1568) Implement Spatial Filter

[Ryan McKinley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12796280#action_12796280
 ] 

Ryan McKinley commented on SOLR-1568:
-

I'm torn on this also...

The function query syntax (and all local params really) are a bit cryptic.  
When I look into it though they are really powerful, and i see an advantage to 
having that level of control. (and it works in solr now)

I wonder if there is a simple way to add query rewriting that would convert:
 &lat=49&long=-77&radius=10
to:
 &fq={!sfilt p=49,-77 f=location dist=10}

Perhaps a RequestRewrite component?  

I doubt adding something like http://tuckey.org/urlrewrite/ would work 
off-the-shelf, but it could go a long way to hide the ugly innards for a simple 
case like this, yet still allow the power of the function query syntax.


> Implement Spatial Filter
> 
>
> Key: SOLR-1568
> URL: https://issues.apache.org/jira/browse/SOLR-1568
> Project: Solr
>  Issue Type: New Feature
>Reporter: Grant Ingersoll
>Assignee: Grant Ingersoll
>Priority: Minor
> Fix For: 1.5
>
> Attachments: CartesianTierQParserPlugin.java
>
>
> Given an index with spatial information (either as a geohash, 
> SpatialTileField (see SOLR-1586) or just two lat/lon pairs), we should be 
> able to pass in a filter query that takes in the field name, lat, lon and 
> distance and produces an appropriate Filter (i.e. one that is aware of the 
> underlying field type for use by Solr. 
> The interface _could_ look like:
> {code}
> &fq={!sfilt dist=20}location:49.32,-79.0
> {code}
> or it could be:
> {code}
> &fq={!sfilt lat=49.32 lat=-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt p=49.32,-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt lat=49.32,-79.0 fl=lat,lon dist=20}
> {code}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1694) DocFrequencyValueSource

[Ryan McKinley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12796079#action_12796079
 ] 

Ryan McKinley commented on SOLR-1694:
-

I don't know if folks think this is generally useful...  if yes, then I would 
love feedback and move forward on commiting.

If not, i can just use it as a plugin

> DocFrequencyValueSource
> ---
>
> Key: SOLR-1694
> URL: https://issues.apache.org/jira/browse/SOLR-1694
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Reporter: Ryan McKinley
>Priority: Minor
> Attachments: SOLR-1694-DocFrequencyValueSource.patch
>
>
> A ValueSource to expose the document frequency for a given field.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-1694) DocFrequencyValueSource

[Ryan McKinley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-1694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan McKinley updated SOLR-1694:


Attachment: SOLR-1694-DocFrequencyValueSource.patch

This is a first draft, it gets the DF with:
{code:java}
public DocValues getValues(Map context, final IndexReader reader) throws 
IOException 
  {
final String[] arr = cache.getStrings(reader, field);
return new DocValues() {

  public int intVal(int doc) 
  {
try {
  int v = reader.docFreq( new Term( qfield, arr[doc] ) ); 
  //System.out.println( "DF("+arr[doc]+":"+v );
  return v;
} 
catch (IOException e) {
  e.printStackTrace();
}
return 0;
  }
{code}

You call the function with:
{code}
 http://localhost:3456/solr/select?q=*:*&sort=df(id,links) desc
{code}

NOTE: right now this only works with string fields




> DocFrequencyValueSource
> ---
>
> Key: SOLR-1694
> URL: https://issues.apache.org/jira/browse/SOLR-1694
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Reporter: Ryan McKinley
>Priority: Minor
> Attachments: SOLR-1694-DocFrequencyValueSource.patch
>
>
> A ValueSource to expose the document frequency for a given field.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1694) DocFrequencyValueSource

[Ryan McKinley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12796071#action_12796071
 ] 

Ryan McKinley commented on SOLR-1694:
-

The use case (mine anyway) is for implementing a Graph structure with Documents.

Consider three documents:
{code}
id: A
links: B
links: C
{code}

{code}
id: B
links: C
{code}

{code}
id: C
{code}

Now, i need to find the documents with the most links.  That is:
A = 0
B = 1  (A)
C = 2  (A and B)

> DocFrequencyValueSource
> ---
>
> Key: SOLR-1694
> URL: https://issues.apache.org/jira/browse/SOLR-1694
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Reporter: Ryan McKinley
>Priority: Minor
>
> A ValueSource to expose the document frequency for a given field.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (SOLR-1694) DocFrequencyValueSource

[Ryan McKinley (JIRA)]

DocFrequencyValueSource
---

 Key: SOLR-1694
 URL: https://issues.apache.org/jira/browse/SOLR-1694
 Project: Solr
  Issue Type: New Feature
  Components: search
Reporter: Ryan McKinley
Priority: Minor


A ValueSource to expose the document frequency for a given field.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1690) JSONKeyValueTokenizerFactory -- JSON Tokenizer

[Ryan McKinley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795737#action_12795737
 ] 

Ryan McKinley commented on SOLR-1690:
-

I have been using it to have structured data stored in a single field.  Kind of 
like a less cryptic version of:
http://wiki.apache.org/solr/UserTagDesign

I'm not sure it belongs in /trunk, but wanted to post it here so that others 
could use it if they want...

> JSONKeyValueTokenizerFactory -- JSON Tokenizer
> --
>
> Key: SOLR-1690
> URL: https://issues.apache.org/jira/browse/SOLR-1690
> Project: Solr
>  Issue Type: New Feature
>  Components: Schema and Analysis
>Reporter: Ryan McKinley
>Priority: Minor
> Attachments: noggit-1.0-A1.jar, 
> SOLR-1690-JSONKeyValueTokenizerFactory.patch
>
>
> Sometimes it is nice to group structured data into a single field.
> This (rough) patch, takes JSON input and indexes tokens based on the key 
> values pairs in the json.
> {code:xml|title=schema.xml}
> 
>  omitNorms="true">
>   
>  hierarchicalKey="false"/>
> 
> 
>   
>   
> 
> 
> 
>   
> 
> {code}
> Given text:
> {code}
>  { "hello": "world", "rank":5 }
> {code}
> indexed as two tokens:
> || term position |1 | 2 |
> || term text |hello:world | rank:5 |
> || term type |word |  word |
> || source start,end | 12,17   | 27,28 |

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there

[Ryan McKinley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795428#action_12795428
 ] 

Ryan McKinley commented on SOLR-1602:
-

| the patch does not apply. iis it not updated to trunk? 

I've never had good luck with patches for moving files.  Even if it applies 
correctly, if you commit the patch, the svn history does not show that the file 
was moved.  (unless this has been fixed in the last year since i looked)

For refactoring like this, whoever commits this will probably need to make the 
changes directly.

> Refactor SOLR package structure to include o.a.solr.response and move 
> QueryResponseWriters in there
> ---
>
> Key: SOLR-1602
> URL: https://issues.apache.org/jira/browse/SOLR-1602
> Project: Solr
>  Issue Type: Improvement
>  Components: Response Writers
>Affects Versions: 1.2, 1.3, 1.4
> Environment: independent of environment (code structure)
>Reporter: Chris A. Mattmann
>Assignee: Noble Paul
> Fix For: 1.5
>
> Attachments: SOLR-1602.Mattmann.112509.patch.txt, 
> SOLR-1602.Mattmann.112509_02.patch.txt
>
>
> Currently all o.a.solr.request.QueryResponseWriter implementations are 
> curiously located in the o.a.solr.request package. Not only is this package 
> getting big (30+ classes), a lot of them are misplaced. There should be a 
> first-class o.a.solr.response package, and the response related classes 
> should be given a home there. Patch forthcoming.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-1690) JSONKeyValueTokenizerFactory -- JSON Tokenizer

[Ryan McKinley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan McKinley updated SOLR-1690:


Description: 
Sometimes it is nice to group structured data into a single field.

This (rough) patch, takes JSON input and indexes tokens based on the key values 
pairs in the json.

{code:xml|title=schema.xml}


  



  
  



  

{code}

Given text:
{code}
 { "hello": "world", "rank":5 }
{code}

indexed as two tokens:

|| term position |  1 | 2 |
|| term text |  hello:world | rank:5 |
|| term type |  word |  word |
|| source start,end |   12,17   | 27,28 |

  was:
Sometimes it is nice to group structured data into a single field.

This (rough) patch, takes JSON input and indexes tokens based on the key values 
pairs in the json.

For example, the text:
{code}
 { "hello": "world", "rank":5 }
{code}
gets indexed as two tokens:

|| term position |  1 | 2 |
|| term text |  hello:world | rank:5 |
|| term type |  word |  word |
|| source start,end |   12,17   | 27,28 |


> JSONKeyValueTokenizerFactory -- JSON Tokenizer
> --
>
> Key: SOLR-1690
> URL: https://issues.apache.org/jira/browse/SOLR-1690
> Project: Solr
>  Issue Type: New Feature
>  Components: Schema and Analysis
>Reporter: Ryan McKinley
>Priority: Minor
> Attachments: noggit-1.0-A1.jar, 
> SOLR-1690-JSONKeyValueTokenizerFactory.patch
>
>
> Sometimes it is nice to group structured data into a single field.
> This (rough) patch, takes JSON input and indexes tokens based on the key 
> values pairs in the json.
> {code:xml|title=schema.xml}
> 
>  omitNorms="true">
>   
>  hierarchicalKey="false"/>
> 
> 
>   
>   
> 
> 
> 
>   
> 
> {code}
> Given text:
> {code}
>  { "hello": "world", "rank":5 }
> {code}
> indexed as two tokens:
> || term position |1 | 2 |
> || term text |hello:world | rank:5 |
> || term type |word |  word |
> || source start,end | 12,17   | 27,28 |

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-1690) JSONKeyValueTokenizerFactory -- JSON Tokenizer

[Ryan McKinley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan McKinley updated SOLR-1690:


Attachment: noggit-1.0-A1.jar

This tokenizer uses noggit
http://svn.apache.org/repos/asf/labs/noggit/

> JSONKeyValueTokenizerFactory -- JSON Tokenizer
> --
>
> Key: SOLR-1690
> URL: https://issues.apache.org/jira/browse/SOLR-1690
> Project: Solr
>  Issue Type: New Feature
>  Components: Schema and Analysis
>Reporter: Ryan McKinley
>Priority: Minor
> Attachments: noggit-1.0-A1.jar, 
> SOLR-1690-JSONKeyValueTokenizerFactory.patch
>
>
> Sometimes it is nice to group structured data into a single field.
> This (rough) patch, takes JSON input and indexes tokens based on the key 
> values pairs in the json.
> For example, the text:
> {code}
>  { "hello": "world", "rank":5 }
> {code}
> gets indexed as two tokens:
> || term position |1 | 2 |
> || term text |hello:world | rank:5 |
> || term type |word |  word |
> || source start,end | 12,17   | 27,28 |

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-1690) JSONKeyValueTokenizerFactory -- JSON Tokenizer

[Ryan McKinley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan McKinley updated SOLR-1690:


Attachment: SOLR-1690-JSONKeyValueTokenizerFactory.patch

Here is a simple JSON tokenizer.  No tests, but a good place to start if you 
are looking to do something similar.

> JSONKeyValueTokenizerFactory -- JSON Tokenizer
> --
>
> Key: SOLR-1690
> URL: https://issues.apache.org/jira/browse/SOLR-1690
> Project: Solr
>  Issue Type: New Feature
>  Components: Schema and Analysis
>Reporter: Ryan McKinley
>Priority: Minor
> Attachments: SOLR-1690-JSONKeyValueTokenizerFactory.patch
>
>
> Sometimes it is nice to group structured data into a single field.
> This (rough) patch, takes JSON input and indexes tokens based on the key 
> values pairs in the json.
> For example, the text:
> {code}
>  { "hello": "world", "rank":5 }
> {code}
> gets indexed as two tokens:
> || term position |1 | 2 |
> || term text |hello:world | rank:5 |
> || term type |word |  word |
> || source start,end | 12,17   | 27,28 |

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (SOLR-1690) JSONKeyValueTokenizerFactory -- JSON Tokenizer

[Ryan McKinley (JIRA)]

JSONKeyValueTokenizerFactory -- JSON Tokenizer
--

 Key: SOLR-1690
 URL: https://issues.apache.org/jira/browse/SOLR-1690
 Project: Solr
  Issue Type: New Feature
  Components: Schema and Analysis
Reporter: Ryan McKinley
Priority: Minor


Sometimes it is nice to group structured data into a single field.

This (rough) patch, takes JSON input and indexes tokens based on the key values 
pairs in the json.

For example, the text:
{code}
 { "hello": "world", "rank":5 }
{code}
gets indexed as two tokens:

|| term position |  1 | 2 |
|| term text |  hello:world | rank:5 |
|| term type |  word |  word |
|| source start,end |   12,17   | 27,28 |

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [VOTE] SOLR-1602 Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there

[Ryan McKinley]

Here's what you're voting on:

[ x] Yes, move forward with SOLR-1602 with the plan proposed above
[ ] No,  don't move forward with SOLR-1602 because...

I'll leave the vote open for 72 hours. Votes from SOLR committers are
binding, but everyone is welcome to voice your opinion.


Not to throw cold water on the formality... but..  when I suggested we  
get broader approval, i was not thinking about jumping into a formal  
vote...


Seems odd to put a three day window while many people are on vacation :)

ryan

[jira] Commented: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there

[Ryan McKinley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795352#action_12795352
 ] 

Ryan McKinley commented on SOLR-1602:
-

| I'm a fan of number 2, and I'd venture to guess the work wouldn't be too bad 
in this case since most of the ReponseWriters aren't friendly to user extension 
or sub-classing.

+1

but since this is a breaking change -- that would need explicitly called out in 
CHANGES.txt, we should get pretty wide consensus before moving forward...

> Refactor SOLR package structure to include o.a.solr.response and move 
> QueryResponseWriters in there
> ---
>
> Key: SOLR-1602
> URL: https://issues.apache.org/jira/browse/SOLR-1602
> Project: Solr
>  Issue Type: Improvement
>  Components: Response Writers
>Affects Versions: 1.2, 1.3, 1.4
> Environment: independent of environment (code structure)
>Reporter: Chris A. Mattmann
> Fix For: 1.5
>
> Attachments: SOLR-1602.Mattmann.112509.patch.txt, 
> SOLR-1602.Mattmann.112509_02.patch.txt
>
>
> Currently all o.a.solr.request.QueryResponseWriter implementations are 
> curiously located in the o.a.solr.request package. Not only is this package 
> getting big (30+ classes), a lot of them are misplaced. There should be a 
> first-class o.a.solr.response package, and the response related classes 
> should be given a home there. Patch forthcoming.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there

[Ryan McKinley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795341#action_12795341
 ] 

Ryan McKinley commented on SOLR-1602:
-

Sounds fine... except for the back compatibility issues -- especially for 
people upgrading with the same solrconfig.xml

When we moved all the handlers to a new package o.a.solr.handler, it left a 
bunch of deprecated calsses in o.a.solr.request:
{code:java}
@Deprecated 
public class StandardRequestHandler extends 
org.apache.solr.handler.StandardRequestHandler {
 // Don't use this class
}
{code}

Also, if we make a 'response' package, seems SolrQueryResponse.java should go 
there.

> Refactor SOLR package structure to include o.a.solr.response and move 
> QueryResponseWriters in there
> ---
>
> Key: SOLR-1602
> URL: https://issues.apache.org/jira/browse/SOLR-1602
> Project: Solr
>  Issue Type: Improvement
>  Components: Response Writers
>Affects Versions: 1.2, 1.3, 1.4
> Environment: independent of environment (code structure)
>Reporter: Chris A. Mattmann
> Fix For: 1.5
>
> Attachments: SOLR-1602.Mattmann.112509.patch.txt, 
> SOLR-1602.Mattmann.112509_02.patch.txt
>
>
> Currently all o.a.solr.request.QueryResponseWriter implementations are 
> curiously located in the o.a.solr.request package. Not only is this package 
> getting big (30+ classes), a lot of them are misplaced. There should be a 
> first-class o.a.solr.response package, and the response related classes 
> should be given a home there. Patch forthcoming.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Solr 1.5 or 2.0?

[Ryan McKinley]

What would a 1.9 release mean in solr?


Dooh -- after hitting send, i realized it would just mean:
Whatever we would do for the next release, but say 'after this, old  
APIs won't be supported'


ryan

Re: Solr 1.5 or 2.0?

[Ryan McKinley]

On Nov 25, 2009, at 11:30 AM, Chris Hostetter wrote:



: > The point being: it's all been very informat up to now -- and  
that's
: > probably for the best.  "policies" should evolve over time based  
on real
: > world situations that come up, and we're still in the process of  
doing

: > that.
:
: Agreed, but now that the elephant has been identified in the room,  
let's
: come up with a policy then. What are your thoughts on my proposal  
(specified

: earlier in this thread)?

The elephant has been identified, and he's in the room, but he's in  
the

far corner and he's not bothering anybody.

my personal preference (at the moment) is to leave things undefined  
for
now ... i'd rather see us get to a point where we say "whoa, here is  
an

actaul in the flesh cross roads where it feels wrong to release w/o
bumping the major version" and then to try and write down a policy  
ahead
of time anticipating what that cross road is and how we we'll want  
to deal

with it.

if it's unspecified, it can be specified later when it actaully  
becomes an
issue -- if it's specified, then people will feel like we are  
beholden to

the specification, even if it doesn't wind up making as much sense in
practice.

(yonik: you're anarchist ways clearly rubbed off on me at apachecon)



I agree with keeping it informal (for now)

I agree with Mark that yes, we should do what we can to make the best  
choices about changes that affect compatibility.  For sure.


The thing about the 1.5/1.9/2.0 question that makes me uncomfortable  
is that it is applying the same 'official' rules from lucene to solr.   
I am not sure how well that maps in practice.  What would a 1.9  
release mean in solr?  (I don't really want an answer, I just don't  
think it means the same thing in solr vs lucene)


Again, i have nothing against calling the next release 2.0 -- I just  
think that 1.5 is also fine and keeps the door open for 2.0 to be a  
more fundamental change in solr (that may or may not happen)


ryan

[jira] Commented: (SOLR-1589) Make FieldType#toInternal throw explicit Exceptions when Field values don't validate

[Ryan McKinley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781282#action_12781282
 ] 

Ryan McKinley commented on SOLR-1589:
-

| But SolrException != HttpRequestException, right? More, it's not a 
ServletContainerException. It's a SolrException

+1, I think it would be good to have some more descriptive exceptions then just 
the HTTP ones.

But I think any new exception classes should extend SolrException with a 
reasonable code.  That is, "InvalidFieldException extends SolrException( 
BAD_REQUEST )"  or something like that.

This way HTTP error codes will get passed correctly, OR the exception can be 
caught and dealt with.



> Make FieldType#toInternal throw explicit Exceptions when Field values don't 
> validate
> 
>
> Key: SOLR-1589
> URL: https://issues.apache.org/jira/browse/SOLR-1589
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 1.4
> Environment: My MacBook pro laptop.
>Reporter: Chris A. Mattmann
>Priority: Minor
> Fix For: 1.5
>
>
> As discussed on the mailing list: 
> http://mail-archives.apache.org/mod_mbox/lucene-solr-dev/200911.mbox/%3c85641490-9e70-41b3-a32e-22935b688...@apache.org%3e
> I think we can do a better job of having explicit Exceptions when there is a 
> problem creating the internal representation of a Field, as defined by 
> FieldType#toInternal. Instead of throwing obscure RuntimeExceptions, let's 
> create a FieldValidationException explicit type, and make 
> o.a.solr.schema.FieldType#toInternal throw this Exception as part of its 
> signature.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Solr 1.5 or 2.0?

[Ryan McKinley]

switching back to solr-dev... sorry for spinning off that thread...




What is a serious change that would warrant a bump in your opinion?


for example:
- config overhaul.  detangle the XML from the components.  perhaps  
using

spring.
This is already done. No components read config from xml anymore  
SOLR-1198


nice work!  I had not seen this.

[jira] Commented: (SOLR-1568) Implement Cartesian Tier Filter

[Ryan McKinley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12779726#action_12779726
 ] 

Ryan McKinley commented on SOLR-1568:
-

| I think the best way is to maintain the code pieces in SOLR, try and flow 
them back into Lucene (those updates needed there), and then flow back into 
SOLR as releases in Lucene-ville are made.

+1



> Implement Cartesian Tier Filter
> ---
>
> Key: SOLR-1568
> URL: https://issues.apache.org/jira/browse/SOLR-1568
> Project: Solr
>  Issue Type: New Feature
>Reporter: Grant Ingersoll
>Assignee: Grant Ingersoll
>Priority: Minor
> Fix For: 1.5
>
> Attachments: CartesianTierQParserPlugin.java
>
>
> Given an index with cartesian tiers, we should be able to pass in a filter 
> query that takes in the field name, lat, lon and radius and produces an 
> appropriate Filter for use by Solr.  Note, contrib/spatial has such a filter, 
> so it may just be that we need to hook in a QParserPlugin to handle it. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Functions as Filters

[Ryan McKinley]

so I don't think any sort of
generic cache is needed for geo.



Agreed, no generic cache for geo.   Was thinking about a generic  
cache for function calculations.


I think even more generally would be good -- an easy way to share  
calculations between anything in the request cycle:  function query,  
search components, request handlers, response writers.


To avoid adding dependencies to stuff that does not need it, perhaps  
it makes sense to use the 'inform' model we have for SolrCoreAware  
type things.


Perhaps (bad name as i'm just throwing stuff out there)  
SharedContextAware / inform( SharedContext )


ryan


 Potentially, we could have the need: sort, filter, facet and boost  
by function.  And that calculation is likely the same over and over  
within a given request.  Of course, if we add the pseudo-fields,  
then that effectively acts as a cache for the request.


-Grant

Re: trunk is now open

[Ryan McKinley]

And a big thank you to Grant for managing this release!

thanks Grant


On Nov 10, 2009, at 10:38 AM, Grant Ingersoll wrote:


Feel free to move forward on 1.5...

Announcement will be sent out shortly on 1.4.  Good work everyone!

-Grant

Re: [VOTE] 1.4 new RC up

[Ryan McKinley]

I don't think holding up 1.4 makes much sense for this...

I assume we will have a 1.4.1 release when lucene 3.0 comes out.   
Hopefully that is soon.


ryan


On Nov 9, 2009, at 10:43 AM, Grant Ingersoll wrote:

I think at this point, I'd rather not.  We've delayed long enough.   
It should have been marked as 1.4 long ago and should have been  
raised as more serious in any of the 4 previous release candidates.


On Nov 9, 2009, at 10:17 AM, Peter Wolanin wrote:

Seems like the dismax escaping still has serious flaws - any chance  
we

can get this bug fixed for 1.4?
https://issues.apache.org/jira/browse/SOLR-874

-Peter

Re: [VOTE] 1.4 new RC up

[Ryan McKinley]

+1


On Nov 6, 2009, at 2:25 PM, Yonik Seeley wrote:


+1 for releasing these artifacts:

1cc3783316aa1f95ba5e250a4c1d0451  apache-solr-1.4.0.tgz
8da9395565736499f80542c8d05b3854  apache-solr-1.4.0.zip

-Yonik
http://www.lucidimagination.com

On Fri, Nov 6, 2009 at 1:28 PM, Grant Ingersoll  
 wrote:
OK, done.  Same place as always.  Looks like the Lucene release is  
finally

going through, so let's get this finished up!

On Nov 5, 2009, at 6:55 PM, Grant Ingersoll wrote:


Sure.  I'll do it tonight or first thing tomorrow morning.


On Nov 5, 2009, at 6:04 PM, Yonik Seeley wrote:

On Thu, Nov 5, 2009 at 7:40 PM, Grant Ingersoll >

wrote:


Hopefully, 4th time is the charm:

http://people.apache.org/~gsingers/solr/1.4.0/


Can we respin???!!!
https://issues.apache.org/jira/browse/SOLR-1543

-Yonik
http://www.lucidimagination.com

Re: [VOTE] Release Solr 1.4.0

[Ryan McKinley]

+1


On Oct 30, 2009, at 12:40 PM, Grant Ingersoll wrote:


OK, take 3: http://people.apache.org/~gsingers/solr/1.4.0/

On Oct 30, 2009, at 8:10 AM, Grant Ingersoll wrote:


Got it.  Will upload shortly.

On Oct 29, 2009, at 8:33 PM, Yonik Seeley wrote:


On Thu, Oct 29, 2009 at 7:36 PM, Yonik Seeley
 wrote:
Lucene 2.9.1 respin 3 vote has started... I'm downloading now and  
will

test + check in.


Done.  You're up Grant!

-Yonik
http://www.lucidimagination.com

Re: [VOTE] Release Solr 1.4.0

[Ryan McKinley]

On Oct 28, 2009, at 9:12 PM, Nicholas Letourneau wrote:


Not sure who gets a vote,


Everyone gets to vote -- officially some votes are 'binding' but in  
practice this does not really matter.


The more feedback there is, the more confidence we have that things  
are good (or need fixed)





and this is my first message to this list, but I
wanted to add that I deployed the maven artifacts (along with the  
lucene
2.9.1 ones) to my in house maven repository and successfully built  
all my

solr dependant projects with

   
 org.apache.solr
 solr-core
 1.4.0
   
   
 org.apache.solr
 solr-solrj
 1.4.0
   

Everything went swimingly and running "mvn dependency:tree" showed  
this

output:

[INFO] +- org.apache.solr:solr-core:jar:1.4.0:compile
[INFO] |  +- org.apache.lucene:lucene-analyzers:jar:2.9.1:compile
[INFO] |  |  \- org.apache.lucene:lucene-core:jar:2.9.1:compile
[INFO] |  +- org.apache.lucene:lucene-highlighter:jar:2.9.1:compile
[INFO] |  +- org.apache.lucene:lucene-queries:jar:2.9.1:compile
[INFO] |  +- org.apache.lucene:lucene-snowball:jar:2.9.1:compile
[INFO] |  +- org.apache.lucene:lucene-memory:jar:2.9.1:compile
[INFO] |  +- org.apache.lucene:lucene-misc:jar:2.9.1:compile
[INFO] |  +- org.apache.lucene:lucene-spellchecker:jar:2.9.1:compile
[INFO] |  +- commons-codec:commons-codec:jar:1.3:compile
[INFO] |  +- commons-fileupload:commons-fileupload:jar:1.2.1:compile
[INFO] |  +- org.apache.solr:solr-commons-csv:jar:1.4.0:compile
[INFO] |  +- woodstox:wstx-asl:jar:3.2.7:compile
[INFO] |  \-
org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:compile
[INFO] \- org.apache.solr:solr-solrj:jar:1.4.0:compile
[INFO]+- org.slf4j:slf4j-api:jar:1.5.5:compile
[INFO]\- org.codehaus.woodstox:wstx-asl:jar:3.2.7:compile
[INFO]   \- stax:stax-api:jar:1.0.1:compile

Nicholas Letourneau

On 10/27/09 10/27 7:07 PM, "Grant Ingersoll"   
wrote:



OK, new artifacts are up.



On Oct 27, 2009, at 9:51 PM, Chris Hostetter wrote:



: By other issues, I mean the duplicate libs.  I think we can live
with them.

I agree ... i would have voted +1 already but i figured based on  
your

commit you were in the process of doing a new one.



-Hoss

Re: [VOTE] Release Solr 1.4.0

[Ryan McKinley]

+1

Integrated with my app, and things work well.  (windows vista)
Ran examples and everything worked as expected.  (Mac OSX)



On Oct 27, 2009, at 10:07 PM, Grant Ingersoll wrote:


OK, new artifacts are up.



On Oct 27, 2009, at 9:51 PM, Chris Hostetter wrote:



: By other issues, I mean the duplicate libs.  I think we can live  
with them.


I agree ... i would have voted +1 already but i figured based on your
commit you were in the process of doing a new one.



-Hoss

Re: [VOTE] Release Solr 1.4.0

[Ryan McKinley]

On Oct 28, 2009, at 12:07 AM, Chris Hostetter wrote:



: It's not a regression, but a new, non-core feature.  If we delay  
every

: time we find a bug, this release will never end.

agreed.



agreed.  And assuming lucene 3.0 comes out in the somewhat near  
future, we will have an easy place for minor bug fixes soon enough.

Re: [VOTE] Release Solr 1.4.0

[Ryan McKinley]

Also, not sure what the policy is on voting on files where the pom  
still needs to change..


http://people.apache.org/~gsingers/solr/1.4.0/maven/org/apache/solr/solr-core/1.4.0/solr-core-1.4.0.pom
points to:

 org.apache.lucene
 lucene-analyzers
 2.9.0


But we really want to point to 2.9.1
I guess we can go ahead and change that even though 2.9.1 does not  
exist in any repository yet?


ryan


On Oct 26, 2009, at 6:35 PM, Yonik Seeley wrote:


Hmmm, weren't you going to update the version numbers to 1.4.1-dev
like we just discussed in the other thread?
That way if someone changes some of the solr source from the download
and recompiles, they don't get a version number of 1.4.0

-Yonik
http://www.lucidimagination.com



On Mon, Oct 26, 2009 at 6:15 PM, Grant Ingersoll  
 wrote:

Tis the season for releases...

Please vote on releasing the Solr 1.4.0 artifacts located at
http://people.apache.org/~gsingers/solr/1.4.0/  (note, solr.tar and
solr-maven.tar are not artifacts to be released)

CHANGES are spelled out at
https://svn.apache.org/repos/asf/lucene/solr/branches/branch-1.4/CHANGES.txt

Thanks,
Grant

Re: Another RC

[Ryan McKinley]

On Oct 26, 2009, at 4:00 PM, Grant Ingersoll wrote:


So, just to clarify, here's the plan as I understand it:

1. Put up a 1.4.0 RC today w/ 2.9.1-RC2
2. Commence vote on 1.4.0
3. Once 2.9.1 is finalized, replace in Solr and generate final  
artifacts


We also must make sure the maven pom.xml points to the right place.   
(currently it still points to 2.9... not the solr specific ones)




4. Release

Is that correct?  This basically works on the assumption that the  
only thing that has changed between 2.9.1-RC2 and 2.9.1 final is the  
name of the jars.  If that is the case, I'm fine w/ this process.




sounds good.  Thanks Grant!




-Grant

On Oct 19, 2009, at 5:57 PM, Yonik Seeley wrote:

OK, so let's do the following: as soon as the Lucene 2.9.1 official  
RC
is put up (the one that will be voted on), I'll update Solr and we  
can

do our vote at the same time, saving 3 or 4 days... this release has
really been held up long enough :-)

We can re-evaluate what to do if for some reason the Lucene vote
doesn't pass (i.e., we won't blindly release Solr if the lucene vote
fails).

Hopefully everyone has looked at the latest Solr distributions for  
any

potential showstoppers that would cause them to vote -1 during the
official vote.

-Yonik
http://www.lucidimagination.com

On Mon, Oct 19, 2009 at 1:35 PM, Walter Underwood > wrote:
Please wait for an official release of Lucene. It makes thing SO  
much easier

when you need to dig into the Lucene code.

It is well worth a week delay.

wunder

On Oct 19, 2009, at 10:27 AM, Yonik Seeley wrote:

On Mon, Oct 19, 2009 at 10:59 AM, Grant Ingersoll >

wrote:


Are we ready for a release?


+1

I don't think we need to wait for Lucene 2.9.1 - we have all the  
fixes

in our version, and there's little point in pushing things off yet
another week.

Seems like the next RC should be a *real* one (i.e. no RC label  
in the

version, immediately call a VOTE).

-Yonik
http://www.lucidimagination.com


I got busy at work and haven't been able to
address things as much, but it seems like things are progressing.

Shall I generate another RC or are we waiting for Lucene 2.9.1?   
If we go

w/
the 2.9.1-dev, then we just need to restore the Maven stuff for  
them.
Hopefully, that stuff was just commented out and not completely  
removed

so
as to make it a little easier to restore.

-Grant

Re: Another RC

[Ryan McKinley]

I've been testing with jetty 7.0.0.v20091005, and everything works  
good so far..



On Oct 25, 2009, at 3:59 PM, Yonik Seeley wrote:

If all goes well in lucene-land 2.9.1 should start a vote on Monday  
sometime...


I've recently tested the latest stable Jetty (6.1.21) ... so we can
avoid some duplication, has anyone tested with the latest tomcat,
resin, or other popular servlet containers?

-Yonik
http://www.lucidimagination.com


On Mon, Oct 19, 2009 at 5:57 PM, Yonik Seeley
 wrote:
OK, so let's do the following: as soon as the Lucene 2.9.1 official  
RC
is put up (the one that will be voted on), I'll update Solr and we  
can

do our vote at the same time, saving 3 or 4 days... this release has
really been held up long enough :-)

We can re-evaluate what to do if for some reason the Lucene vote
doesn't pass (i.e., we won't blindly release Solr if the lucene vote
fails).

Hopefully everyone has looked at the latest Solr distributions for  
any

potential showstoppers that would cause them to vote -1 during the
official vote.

-Yonik
http://www.lucidimagination.com

On Mon, Oct 19, 2009 at 1:35 PM, Walter Underwood > wrote:
Please wait for an official release of Lucene. It makes thing SO  
much easier

when you need to dig into the Lucene code.

It is well worth a week delay.

wunder

On Oct 19, 2009, at 10:27 AM, Yonik Seeley wrote:

On Mon, Oct 19, 2009 at 10:59 AM, Grant Ingersoll >

wrote:


Are we ready for a release?


+1

I don't think we need to wait for Lucene 2.9.1 - we have all the  
fixes

in our version, and there's little point in pushing things off yet
another week.

Seems like the next RC should be a *real* one (i.e. no RC label  
in the

version, immediately call a VOTE).

-Yonik
http://www.lucidimagination.com


 I got busy at work and haven't been able to
address things as much, but it seems like things are progressing.

Shall I generate another RC or are we waiting for Lucene 2.9.1?   
If we go

w/
the 2.9.1-dev, then we just need to restore the Maven stuff for  
them.
 Hopefully, that stuff was just commented out and not completely  
removed

so
as to make it a little easier to restore.

-Grant

minor nit....

[Ryan McKinley]

I'm looking through a bunch of logs that have:
UpdateRequestProcessor - {add=[aa, bb, cc, dd, ee, ff, gg, hh, ...(142 more)]}

Would it be more reasonable to say: "150 total" rather then make you
count the previous 8?

kinda stupid, but i guess this is what drives you nuts while chasing
real problems...

ryan

Re: Outdated luke

[Ryan McKinley]

thanks for pointing this out.  Check:  SOLR-1512, now fixed in trunk

thanks
ryan


On Oct 15, 2009, at 10:58 AM, Colin Hynes wrote:

I just thought I'd toss a note out that in the main build.xml it's  
fetching a outdated vesions of luke(0.9.1) and lucene(2.4).


For the solr 1.4 release, that should probably change to:

luke 0.9.9
lucene 2.9


-Colin


Active Media Architects, Inc.
World Class Design, Programming & Strategy - Since 1998
http://www.activema.com

1-888-392-4567 toll free
1-586-445-1000 local
1-586-445-2247 fax

[jira] Resolved: (SOLR-1512) point build.xml to luke 0.9.9

[Ryan McKinley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-1512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan McKinley resolved SOLR-1512.
-

Resolution: Fixed

> point build.xml to luke 0.9.9
> -
>
> Key: SOLR-1512
> URL: https://issues.apache.org/jira/browse/SOLR-1512
> Project: Solr
>  Issue Type: Task
>    Reporter: Ryan McKinley
>Priority: Minor
> Fix For: 1.4
>
> Attachments: SOLR-1512-luke.patch
>
>
> The luke launcher should point to luke 0.9.9

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-1512) point build.xml to luke 0.9.9

[Ryan McKinley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-1512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan McKinley updated SOLR-1512:


Attachment: SOLR-1512-luke.patch

pointing to luke 0.9.9

> point build.xml to luke 0.9.9
> -
>
> Key: SOLR-1512
> URL: https://issues.apache.org/jira/browse/SOLR-1512
> Project: Solr
>  Issue Type: Task
>    Reporter: Ryan McKinley
>Priority: Minor
> Fix For: 1.4
>
> Attachments: SOLR-1512-luke.patch
>
>
> The luke launcher should point to luke 0.9.9

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (SOLR-1512) point build.xml to luke 0.9.9

[Ryan McKinley (JIRA)]

point build.xml to luke 0.9.9
-

 Key: SOLR-1512
 URL: https://issues.apache.org/jira/browse/SOLR-1512
 Project: Solr
  Issue Type: Task
Reporter: Ryan McKinley
Priority: Minor
 Fix For: 1.4


The luke launcher should point to luke 0.9.9



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1510) EmbeddedSolrServer should support multiple cores

[Ryan McKinley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12765582#action_12765582
 ] 

Ryan McKinley commented on SOLR-1510:
-

we went back and forth on this one for a while.  Originally solrj knew how to 
handle different cores.

What is the advantage of a single EmbeddedSolrServer talking to multiple cores 
vs an EmbeddedSolrServer for each core?  (perhaps in a 
Map) 

IIRC, adding cores to the SolrServer API gets complicated with the HTTP version 
-- but I don't remember exactly why.

> EmbeddedSolrServer should support multiple cores
> 
>
> Key: SOLR-1510
> URL: https://issues.apache.org/jira/browse/SOLR-1510
> Project: Solr
>  Issue Type: Improvement
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Minor
> Fix For: 1.5
>
>
> currently , EmbeddedSolrServer can be started only with single core. This 
> restriction should be removed

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: another one for 1.4?

[Ryan McKinley]

i say we leave it out...

That is a direct mapping of the XML format to JSON.  I think  
discussion suggested we may want to munge the format a bit before  
baking it into the code.



On Oct 12, 2009, at 4:42 PM, Grant Ingersoll wrote:


I think we leave it out.

On Oct 12, 2009, at 4:27 PM, Erik Hatcher wrote:

http://issues.apache.org/jira/browse/SOLR-945 - JSON update  
handler, comments mention it could/should make it to 1.4.  Just  
came across it again, was curious.


Erik

Down to Zero!

[Ryan McKinley]

Looks like we are down to zero issues:
https://issues.apache.org/jira/secure/BrowseVersion.jspa?id=12310230&versionId=12313351&showOpenIssuesOnly=true

[jira] Resolved: (SOLR-1497) Remove solrjs from svn -- point docs to AJAX Solr

[Ryan McKinley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan McKinley resolved SOLR-1497.
-

Resolution: Fixed

solrjs was removed in rev 824396

This can be pulled from subversion history if necessary

> Remove solrjs from svn -- point docs to AJAX Solr
> -
>
> Key: SOLR-1497
> URL: https://issues.apache.org/jira/browse/SOLR-1497
> Project: Solr
>  Issue Type: Task
>    Reporter: Ryan McKinley
>Assignee: Ryan McKinley
> Fix For: 1.4
>
>
> The solrjs version in solr source tree needs some attention, yet progress 
> seems unlikely.  Meanwhile, AJAX solr (a solrjs fork) has made good progress 
> and seems that it will be supported moving forward.  
> We should archive solrjs and remove it from the source tree.
> For discussion, see:
> http://www.lucidimagination.com/search/document/900bf257f8df4e37/archive_solrjs_and_point_to_ajax_solr#13f6cb2ec40ae1f0

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Down to 1

[Ryan McKinley]

I'm on it!   At least it is easy...


On Oct 10, 2009, at 3:13 PM, Grant Ingersoll wrote:


Down to 1:  
https://issues.apache.org/jira/secure/BrowseVersion.jspa?id=12310230&versionId=12313351&showOpenIssuesOnly=true

Things are looking good for Monday.  I'd encourage everyone to check  
out trunk and hit it with tests, etc. and post feedback here.


-Grant

[jira] Resolved: (SOLR-1434) Evaluate Including SolrJS

[Ryan McKinley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan McKinley resolved SOLR-1434.
-

   Resolution: Fixed
Fix Version/s: 1.4

See SOLR-1497

> Evaluate Including SolrJS
> -
>
> Key: SOLR-1434
> URL: https://issues.apache.org/jira/browse/SOLR-1434
> Project: Solr
>  Issue Type: Task
>Reporter: Grant Ingersoll
>Priority: Blocker
> Fix For: 1.4
>
>
> SolrJS needs to be evaluated for inclusion in the release.  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (SOLR-1294) SolrJS/Javascript client fails in IE8!

[Ryan McKinley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan McKinley resolved SOLR-1294.
-

Resolution: Won't Fix

With SOLR-1497, solrjs devlopment will move to AJAX solr on github

> SolrJS/Javascript client fails in IE8!
> --
>
> Key: SOLR-1294
> URL: https://issues.apache.org/jira/browse/SOLR-1294
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Eric Pugh
>Assignee: Ryan McKinley
> Fix For: 1.4
>
> Attachments: jscalendar.tar, SOLR-1294-full.patch, 
> SOLR-1294-IE8.patch, SOLR-1294.patch, solrjs-ie8-html-syntax-error.patch
>
>
> SolrJS seems to fail with "'jQuery.solrjs' is null or not an object" errors 
> under IE8.  I am continuing to test if this occurs in IE 6 and 7 as well.  
> This happens on both the Sample online site at 
> http://solrjs.solrstuff.org/test/reuters/ as well as the 
> /trunk/contrib/javascript library.   Seems to be a show stopper from the 
> standpoint of really using this library!
> I have posted a screenshot of the error at 
> http://img.skitch.com/20090717-jejm71u6ghf2dpn3mwrkarigwm.png
> The error is just a whole bunch of repeated messages in the vein of:
> Message: 'jQuery.solrjs' is null or not an object
> Line: 24
> Char: 1
> Code: 0
> URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/QueryItem.js
> Message: 'jQuery.solrjs' is null or not an object
> Line: 37
> Char: 1
> Code: 0
> URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/Manager.js
> Message: 'jQuery.solrjs' is null or not an object
> Line: 24
> Char: 1
> Code: 0
> URI: 
> file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/AbstractSelectionView.js
> Message: 'jQuery.solrjs' is null or not an object
> Line: 27
> Char: 1
> Code: 0
> URI: 
> file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/AbstractWidget.js

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (SOLR-1497) Remove solrjs from svn -- point docs to AJAX Solr

[Ryan McKinley (JIRA)]

Remove solrjs from svn -- point docs to AJAX Solr
-

 Key: SOLR-1497
 URL: https://issues.apache.org/jira/browse/SOLR-1497
 Project: Solr
  Issue Type: Task
Reporter: Ryan McKinley
Assignee: Ryan McKinley
 Fix For: 1.4


The solrjs version in solr source tree needs some attention, yet progress seems 
unlikely.  Meanwhile, AJAX solr (a solrjs fork) has made good progress and 
seems that it will be supported moving forward.  

We should archive solrjs and remove it from the source tree.

For discussion, see:
http://www.lucidimagination.com/search/document/900bf257f8df4e37/archive_solrjs_and_point_to_ajax_solr#13f6cb2ec40ae1f0

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1294) SolrJS/Javascript client fails in IE8!

[Ryan McKinley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12762866#action_12762866
 ] 

Ryan McKinley commented on SOLR-1294:
-

excellent -- thank you

> SolrJS/Javascript client fails in IE8!
> --
>
> Key: SOLR-1294
> URL: https://issues.apache.org/jira/browse/SOLR-1294
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Eric Pugh
>    Assignee: Ryan McKinley
> Fix For: 1.4
>
> Attachments: jscalendar.tar, SOLR-1294-full.patch, 
> SOLR-1294-IE8.patch, SOLR-1294.patch, solrjs-ie8-html-syntax-error.patch
>
>
> SolrJS seems to fail with "'jQuery.solrjs' is null or not an object" errors 
> under IE8.  I am continuing to test if this occurs in IE 6 and 7 as well.  
> This happens on both the Sample online site at 
> http://solrjs.solrstuff.org/test/reuters/ as well as the 
> /trunk/contrib/javascript library.   Seems to be a show stopper from the 
> standpoint of really using this library!
> I have posted a screenshot of the error at 
> http://img.skitch.com/20090717-jejm71u6ghf2dpn3mwrkarigwm.png
> The error is just a whole bunch of repeated messages in the vein of:
> Message: 'jQuery.solrjs' is null or not an object
> Line: 24
> Char: 1
> Code: 0
> URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/QueryItem.js
> Message: 'jQuery.solrjs' is null or not an object
> Line: 37
> Char: 1
> Code: 0
> URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/Manager.js
> Message: 'jQuery.solrjs' is null or not an object
> Line: 24
> Char: 1
> Code: 0
> URI: 
> file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/AbstractSelectionView.js
> Message: 'jQuery.solrjs' is null or not an object
> Line: 27
> Char: 1
> Code: 0
> URI: 
> file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/AbstractWidget.js

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

archive solrjs and point to AJAX Solr?

[Ryan McKinley]

I don't think solrjs should hold up the 1.4 release.

Since this issue was last discussed, James McKinney has licensed AJAX  
Solr (a solrjs fork) under Apache & MIT

http://github.com/evolvingweb/AJAX-Solr/blob/master/COPYRIGHT.txt

It seems like this has good support and gets the on-going attention it  
deserves.


I suggest we archive solrjs -- remove it from the 1.4 release -- and  
point javascript client lovers to AJAX-Solr.


If we do "archive" solrjs, what do you think the best method is?
1. svn copy it to /sandbox?
2. make a zip and place it on an external site, remove it entirely  
from solr svn


I lean towards option 1.

thoughts
ryan

[jira] Issue Comment Edited: (SOLR-1294) SolrJS/Javascript client fails in IE8!

[Ryan McKinley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12762864#action_12762864
 ] 

Ryan McKinley edited comment on SOLR-1294 at 10/6/09 9:17 PM:
--

In your 'COPYRIGHT.txt' file, it says:
{code}
AJAX Solr includes works under other copyright notices and distributed
according to the terms of the GNU General Public License or a compatible
license, including:
 
  jQuery strftime plugin - Copyright (c) 2008 Emmanuel Benoît
{code}
If that is true, the Apache/MIT licenses don't help much...  

BUT it seems to me that strftime is distributed under the MIT license:
 http://projects.nocternity.net/index.py/en/jquery-strftime

Are there other things in the code that are GPL?  (sorry for all the license 
haggling, it just turns out to be a blocker issue)  If strftime is not GPL, can 
you remove the notice about GPL code?  (obviously only if that is true)

thanks again


  was (Author: ryantxu):
In your 'COPYRIGHT.txt' file, it says:
[panel]
AJAX Solr includes works under other copyright notices and distributed
according to the terms of the GNU General Public License or a compatible
license, including:
 
  jQuery strftime plugin - Copyright (c) 2008 Emmanuel Benoît
[panel]
If that is true, the Apache/MIT licenses don't help much...  

BUT it seems to me that strftime is distributed under the MIT license:
 http://projects.nocternity.net/index.py/en/jquery-strftime

Are there other things in the code that are GPL?  (sorry for all the license 
haggling, it just turns out to be a blocker issue)  If strftime is not GPL, can 
you remove the notice about GPL code?  (obviously only if that is true)

thanks again

  
> SolrJS/Javascript client fails in IE8!
> --
>
> Key: SOLR-1294
> URL: https://issues.apache.org/jira/browse/SOLR-1294
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 1.4
>    Reporter: Eric Pugh
>Assignee: Ryan McKinley
> Fix For: 1.4
>
> Attachments: jscalendar.tar, SOLR-1294-full.patch, 
> SOLR-1294-IE8.patch, SOLR-1294.patch, solrjs-ie8-html-syntax-error.patch
>
>
> SolrJS seems to fail with "'jQuery.solrjs' is null or not an object" errors 
> under IE8.  I am continuing to test if this occurs in IE 6 and 7 as well.  
> This happens on both the Sample online site at 
> http://solrjs.solrstuff.org/test/reuters/ as well as the 
> /trunk/contrib/javascript library.   Seems to be a show stopper from the 
> standpoint of really using this library!
> I have posted a screenshot of the error at 
> http://img.skitch.com/20090717-jejm71u6ghf2dpn3mwrkarigwm.png
> The error is just a whole bunch of repeated messages in the vein of:
> Message: 'jQuery.solrjs' is null or not an object
> Line: 24
> Char: 1
> Code: 0
> URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/QueryItem.js
> Message: 'jQuery.solrjs' is null or not an object
> Line: 37
> Char: 1
> Code: 0
> URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/Manager.js
> Message: 'jQuery.solrjs' is null or not an object
> Line: 24
> Char: 1
> Code: 0
> URI: 
> file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/AbstractSelectionView.js
> Message: 'jQuery.solrjs' is null or not an object
> Line: 27
> Char: 1
> Code: 0
> URI: 
> file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/AbstractWidget.js

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1294) SolrJS/Javascript client fails in IE8!

[Ryan McKinley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12762864#action_12762864
 ] 

Ryan McKinley commented on SOLR-1294:
-

In your 'COPYRIGHT.txt' file, it says:
[panel]
AJAX Solr includes works under other copyright notices and distributed
according to the terms of the GNU General Public License or a compatible
license, including:
 
  jQuery strftime plugin - Copyright (c) 2008 Emmanuel Benoît
[panel]
If that is true, the Apache/MIT licenses don't help much...  

BUT it seems to me that strftime is distributed under the MIT license:
 http://projects.nocternity.net/index.py/en/jquery-strftime

Are there other things in the code that are GPL?  (sorry for all the license 
haggling, it just turns out to be a blocker issue)  If strftime is not GPL, can 
you remove the notice about GPL code?  (obviously only if that is true)

thanks again


> SolrJS/Javascript client fails in IE8!
> --
>
> Key: SOLR-1294
> URL: https://issues.apache.org/jira/browse/SOLR-1294
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 1.4
>    Reporter: Eric Pugh
>Assignee: Ryan McKinley
> Fix For: 1.4
>
> Attachments: jscalendar.tar, SOLR-1294-full.patch, 
> SOLR-1294-IE8.patch, SOLR-1294.patch, solrjs-ie8-html-syntax-error.patch
>
>
> SolrJS seems to fail with "'jQuery.solrjs' is null or not an object" errors 
> under IE8.  I am continuing to test if this occurs in IE 6 and 7 as well.  
> This happens on both the Sample online site at 
> http://solrjs.solrstuff.org/test/reuters/ as well as the 
> /trunk/contrib/javascript library.   Seems to be a show stopper from the 
> standpoint of really using this library!
> I have posted a screenshot of the error at 
> http://img.skitch.com/20090717-jejm71u6ghf2dpn3mwrkarigwm.png
> The error is just a whole bunch of repeated messages in the vein of:
> Message: 'jQuery.solrjs' is null or not an object
> Line: 24
> Char: 1
> Code: 0
> URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/QueryItem.js
> Message: 'jQuery.solrjs' is null or not an object
> Line: 37
> Char: 1
> Code: 0
> URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/Manager.js
> Message: 'jQuery.solrjs' is null or not an object
> Line: 24
> Char: 1
> Code: 0
> URI: 
> file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/AbstractSelectionView.js
> Message: 'jQuery.solrjs' is null or not an object
> Line: 27
> Char: 1
> Code: 0
> URI: 
> file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/AbstractWidget.js

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1294) SolrJS/Javascript client fails in IE8!

[Ryan McKinley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12762860#action_12762860
 ] 

Ryan McKinley commented on SOLR-1294:
-

sweet.  If AJAX-Solr is Apache licensed, then I feel pretty good about 
archiving solrjs and focusing future attention towards AJAX-Solr.

The concern with "split the community" is that many people in Apache land can 
not touch GPL code (myself included).  With that constraint there would need to 
be two parallel efforts.

Since AJAX-Solr is now Apache/MIT licensed, I see no reason to try to keep 
solrjs up-to-snuff, and think we can just point to AJAX-Solr.  Lets check with 
solr-dev before dropping solrjs, but I think this is the best route forward.

yaay.



> SolrJS/Javascript client fails in IE8!
> --
>
> Key: SOLR-1294
> URL: https://issues.apache.org/jira/browse/SOLR-1294
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Eric Pugh
>Assignee: Ryan McKinley
> Fix For: 1.4
>
> Attachments: jscalendar.tar, SOLR-1294-full.patch, 
> SOLR-1294-IE8.patch, SOLR-1294.patch, solrjs-ie8-html-syntax-error.patch
>
>
> SolrJS seems to fail with "'jQuery.solrjs' is null or not an object" errors 
> under IE8.  I am continuing to test if this occurs in IE 6 and 7 as well.  
> This happens on both the Sample online site at 
> http://solrjs.solrstuff.org/test/reuters/ as well as the 
> /trunk/contrib/javascript library.   Seems to be a show stopper from the 
> standpoint of really using this library!
> I have posted a screenshot of the error at 
> http://img.skitch.com/20090717-jejm71u6ghf2dpn3mwrkarigwm.png
> The error is just a whole bunch of repeated messages in the vein of:
> Message: 'jQuery.solrjs' is null or not an object
> Line: 24
> Char: 1
> Code: 0
> URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/QueryItem.js
> Message: 'jQuery.solrjs' is null or not an object
> Line: 37
> Char: 1
> Code: 0
> URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/Manager.js
> Message: 'jQuery.solrjs' is null or not an object
> Line: 24
> Char: 1
> Code: 0
> URI: 
> file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/AbstractSelectionView.js
> Message: 'jQuery.solrjs' is null or not an object
> Line: 27
> Char: 1
> Code: 0
> URI: 
> file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/AbstractWidget.js

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1294) SolrJS/Javascript client fails in IE8!

[Ryan McKinley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12762848#action_12762848
 ] 

Ryan McKinley commented on SOLR-1294:
-

Looking over it, it seems interesting...  what is the license?  I see GPL, 
Apache, and MIT...  is this offered under multiple licenses?  While any fork of 
Apache code can do pretty much do whatever you like, it seems odd to split the 
community.  I would love to adopt/promote the best solution available, but 
there will always be a need to an Apache style license (LGPL at the minimum)

ryan


> SolrJS/Javascript client fails in IE8!
> --
>
> Key: SOLR-1294
> URL: https://issues.apache.org/jira/browse/SOLR-1294
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Eric Pugh
>    Assignee: Ryan McKinley
> Fix For: 1.4
>
> Attachments: jscalendar.tar, SOLR-1294-full.patch, 
> SOLR-1294-IE8.patch, SOLR-1294.patch, solrjs-ie8-html-syntax-error.patch
>
>
> SolrJS seems to fail with "'jQuery.solrjs' is null or not an object" errors 
> under IE8.  I am continuing to test if this occurs in IE 6 and 7 as well.  
> This happens on both the Sample online site at 
> http://solrjs.solrstuff.org/test/reuters/ as well as the 
> /trunk/contrib/javascript library.   Seems to be a show stopper from the 
> standpoint of really using this library!
> I have posted a screenshot of the error at 
> http://img.skitch.com/20090717-jejm71u6ghf2dpn3mwrkarigwm.png
> The error is just a whole bunch of repeated messages in the vein of:
> Message: 'jQuery.solrjs' is null or not an object
> Line: 24
> Char: 1
> Code: 0
> URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/QueryItem.js
> Message: 'jQuery.solrjs' is null or not an object
> Line: 37
> Char: 1
> Code: 0
> URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/Manager.js
> Message: 'jQuery.solrjs' is null or not an object
> Line: 24
> Char: 1
> Code: 0
> URI: 
> file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/AbstractSelectionView.js
> Message: 'jQuery.solrjs' is null or not an object
> Line: 27
> Char: 1
> Code: 0
> URI: 
> file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/AbstractWidget.js

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (SOLR-1472) upgrade maven poms to reference lucene 2.9 artifacts rather than solr-lucene artifacts

[Ryan McKinley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan McKinley resolved SOLR-1472.
-

Resolution: Fixed

committed in rev819835

When we want to use lucene snapshots again, we can get the template from this 
patch or svn history.

> upgrade maven poms to reference lucene 2.9 artifacts rather than solr-lucene 
> artifacts
> --
>
> Key: SOLR-1472
> URL: https://issues.apache.org/jira/browse/SOLR-1472
> Project: Solr
>  Issue Type: Task
>Affects Versions: 1.4
>    Reporter: Ryan McKinley
>    Assignee: Ryan McKinley
>Priority: Blocker
> Fix For: 1.4
>
> Attachments: SOLR-1472-maven-cleanup.patch
>
>
> Currently, the solr pom.xml files reference solr-lucene jar files.  Rather 
> then reference the solr jars, we should reference the real lucene jar files.
> Additionally, we need to add a reference to "lucene-memory" so we avoid:
> {code}
> java.lang.NoClassDefFoundError: org/apache/lucene/index/memory/MemoryIndex
>   at 
> org.apache.lucene.search.highlight.WeightedSpanTermExtractor.getReaderForField(WeightedSpanTermExtractor.java:313)
>   at 
> org.apache.lucene.search.highlight.WeightedSpanTermExtractor.extractWeightedSpanTerms(WeightedSpanTermExtractor.java:239)
> {code}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-1472) upgrade maven poms to reference lucene 2.9 artifacts rather than solr-lucene artifacts

[Ryan McKinley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan McKinley updated SOLR-1472:


Attachment: SOLR-1472-maven-cleanup.patch

deleting the solr specific maven files.

I will go ahead and commit this

> upgrade maven poms to reference lucene 2.9 artifacts rather than solr-lucene 
> artifacts
> --
>
> Key: SOLR-1472
> URL: https://issues.apache.org/jira/browse/SOLR-1472
> Project: Solr
>  Issue Type: Task
>Affects Versions: 1.4
>    Reporter: Ryan McKinley
>    Assignee: Ryan McKinley
>Priority: Blocker
> Fix For: 1.4
>
> Attachments: SOLR-1472-maven-cleanup.patch
>
>
> Currently, the solr pom.xml files reference solr-lucene jar files.  Rather 
> then reference the solr jars, we should reference the real lucene jar files.
> Additionally, we need to add a reference to "lucene-memory" so we avoid:
> {code}
> java.lang.NoClassDefFoundError: org/apache/lucene/index/memory/MemoryIndex
>   at 
> org.apache.lucene.search.highlight.WeightedSpanTermExtractor.getReaderForField(WeightedSpanTermExtractor.java:313)
>   at 
> org.apache.lucene.search.highlight.WeightedSpanTermExtractor.extractWeightedSpanTerms(WeightedSpanTermExtractor.java:239)
> {code}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (SOLR-1472) upgrade maven poms to reference lucene 2.9 artifacts rather then solr-lucene artifacts

[Ryan McKinley (JIRA)]

upgrade maven poms to reference lucene 2.9 artifacts rather then solr-lucene 
artifacts
--

 Key: SOLR-1472
 URL: https://issues.apache.org/jira/browse/SOLR-1472
 Project: Solr
  Issue Type: Task
Affects Versions: 1.4
Reporter: Ryan McKinley
Assignee: Ryan McKinley
Priority: Blocker
 Fix For: 1.4


Currently, the solr pom.xml files reference solr-lucene jar files.  Rather then 
reference the solr jars, we should reference the real lucene jar files.

Additionally, we need to add a reference to "lucene-memory" so we avoid:
{code}
java.lang.NoClassDefFoundError: org/apache/lucene/index/memory/MemoryIndex
at 
org.apache.lucene.search.highlight.WeightedSpanTermExtractor.getReaderForField(WeightedSpanTermExtractor.java:313)
at 
org.apache.lucene.search.highlight.WeightedSpanTermExtractor.extractWeightedSpanTerms(WeightedSpanTermExtractor.java:239)
{code}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-1472) upgrade maven poms to reference lucene 2.9 artifacts rather than solr-lucene artifacts

[Ryan McKinley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan McKinley updated SOLR-1472:


Summary: upgrade maven poms to reference lucene 2.9 artifacts rather than 
solr-lucene artifacts  (was: upgrade maven poms to reference lucene 2.9 
artifacts rather then solr-lucene artifacts)

> upgrade maven poms to reference lucene 2.9 artifacts rather than solr-lucene 
> artifacts
> --
>
> Key: SOLR-1472
> URL: https://issues.apache.org/jira/browse/SOLR-1472
> Project: Solr
>  Issue Type: Task
>Affects Versions: 1.4
>    Reporter: Ryan McKinley
>    Assignee: Ryan McKinley
>Priority: Blocker
> Fix For: 1.4
>
>
> Currently, the solr pom.xml files reference solr-lucene jar files.  Rather 
> then reference the solr jars, we should reference the real lucene jar files.
> Additionally, we need to add a reference to "lucene-memory" so we avoid:
> {code}
> java.lang.NoClassDefFoundError: org/apache/lucene/index/memory/MemoryIndex
>   at 
> org.apache.lucene.search.highlight.WeightedSpanTermExtractor.getReaderForField(WeightedSpanTermExtractor.java:313)
>   at 
> org.apache.lucene.search.highlight.WeightedSpanTermExtractor.extractWeightedSpanTerms(WeightedSpanTermExtractor.java:239)
> {code}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: 8 for 1.4

[Ryan McKinley]

can we leave it in svn, but drop it from the release?  logistically,
what is the best way to do this?  Make a branch now, remove it from
/trunk, after release copy it from the branch back into /trunk?

That seems like the best way to kick the can down the road.  I agree
an off-the-shelf apache license jquery client is great.

ryan


On Mon, Sep 28, 2009 at 9:13 PM, Grant Ingersoll  wrote:
> Moving to GPL doesn't seem like a good solution to me, but I don't know what
> else to propose.  Why don't we just hold it from this release, but keep it
> in trunk and encourage the Drupal guys and others to submit their changes?
>  Perhaps by then Matthias or you or someone else will have stepped up.
>
> On Sep 28, 2009, at 7:27 PM, Ryan McKinley wrote:
>
>> I just discussed this off-line with Matthias.  It does not look like
>> he has the time to give this much attention now.  (nor do I)
>>
>> We agreed that the best steps forward are to:
>> 1. Support the Drupal guys GPL port
>> 2. Archive the solrjs code to solrstuff.org
>> 3. Yank solrjs from apache svn (and 1.4 release)
>> 4. Add links to the drupal code (GPL) and the solrjs archive (Apache)
>>
>> Does this sound reasonable to everybody?
>>
>> ryan
>>
>>
>> On Mon, Sep 28, 2009 at 1:27 PM, Grant Ingersoll 
>> wrote:
>>>
>>> Forwarded with permission from Peter Wolanin on a private thread.
>>>
>>> Begin forwarded message:
>>>
>>>> From: Peter Wolanin 
>>>> Date: September 26, 2009 9:43:23 AM EDT
>>>> To: Grant Ingersoll 
>>>>
>>>> Subject: Re: 8 for 1.4
>>>>
>>>> I talked to the guys reworking the JS library for Drupal at Drupalcon
>>>> - they are also having to fork potentially around license as much as
>>>> anything else, since they'd like to distribute via drupal.org, which
>>>> means they were hoping to get the original author to re-license the
>>>> code to them as GPL.
>>>>
>>>> -Peter
>>>>
>>>> On Fri, Sep 25, 2009 at 4:45 PM, Grant Ingersoll 
>>>> wrote:
>>>>>
>>>>> Argh, this was meant for solr-dev.
>>>>>
>>>>> Begin forwarded message:
>>>>>
>>>>>> From: Grant Ingersoll 
>>>>>> Date: September 25, 2009 1:34:32 PM EDT
>>>>>> To: solr-u...@lucene.apache.org
>>>>>> Subject: 8 for 1.4
>>>>>> Reply-To: solr-u...@lucene.apache.org
>>>>>>
>>>>>> Y'all,
>>>>>>
>>>>>> We're down to 8 open issues:
>>>>>>
>>>>>>
>>>>>>  https://issues.apache.org/jira/secure/BrowseVersion.jspa?id=12310230&versionId=12313351&showOpenIssuesOnly=true
>>>>>>
>>>>>> 2 are packaging related, one is dependent on the official 2.9 release
>>>>>> (so
>>>>>> should be taken care of today or tomorrow I suspect) and then we have
>>>>>> a
>>>>>> few
>>>>>> others.
>>>>>>
>>>>>> The only two somewhat major ones are S-1458, S-1294 (more on this in a
>>>>>> mo') and S-1449.
>>>>>>
>>>>>> On S-1294, the SolrJS patch, I yet again have concerns about even
>>>>>> including this, given the lack of activity (from Matthias, the
>>>>>> original
>>>>>> author and others) and the fact that some in the Drupal community have
>>>>>> already forked this to fix the various bugs in it instead of just
>>>>>> submitting
>>>>>> patches.  While I really like the idea of this library (jQuery is
>>>>>> awesome),
>>>>>> I have yet to see interest in the community to maintain it (unless you
>>>>>> count
>>>>>> someone forking it and fixing the bugs in the fork as maintenance) and
>>>>>> I'll
>>>>>> be upfront in admitting I have neither the time nor the patience to
>>>>>> debug
>>>>>> Javascript across the gazillions of browsers out there (I don't even
>>>>>> have IE
>>>>>> on my machine unless you count firing up a VM w/ XP on it) in the
>>>>>> wild.
>>>>>>  Given what I know of most of the other committers here, I suspect
>>>>>> that
>>>>>> is
>>>>>> true for others too.  At a minimum, I think S-1294 should be pushed to
>>>>>> 1.5.
>>>>>>  Next up, I think we consider pulling SolrJS from the release, but
>>>>>> keeping
>>>>>> it in trunk and officially releasing it with either 1.5 or 1.4.1,
>>>>>> assuming
>>>>>> its gotten some love in the meantime.  If by then it has no love, I
>>>>>> vote
>>>>>> we
>>>>>> remove it and let the fork maintain it and point people there.
>>>>>>
>>>>>> -Grant
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Peter M. Wolanin, Ph.D.
>>>> Momentum Specialist,  Acquia. Inc.
>>>> peter.wola...@acquia.com
>>>
>>> --
>>> Grant Ingersoll
>>> http://www.lucidimagination.com/
>>>
>>> Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids) using
>>> Solr/Lucene:
>>> http://www.lucidimagination.com/search
>>>
>>>
>
> --
> Grant Ingersoll
> http://www.lucidimagination.com/
>
> Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids) using
> Solr/Lucene:
> http://www.lucidimagination.com/search
>
>

Re: 8 for 1.4

[Ryan McKinley]

I just discussed this off-line with Matthias.  It does not look like
he has the time to give this much attention now.  (nor do I)

We agreed that the best steps forward are to:
1. Support the Drupal guys GPL port
2. Archive the solrjs code to solrstuff.org
3. Yank solrjs from apache svn (and 1.4 release)
4. Add links to the drupal code (GPL) and the solrjs archive (Apache)

Does this sound reasonable to everybody?

ryan


On Mon, Sep 28, 2009 at 1:27 PM, Grant Ingersoll  wrote:
> Forwarded with permission from Peter Wolanin on a private thread.
>
> Begin forwarded message:
>
>> From: Peter Wolanin 
>> Date: September 26, 2009 9:43:23 AM EDT
>> To: Grant Ingersoll 
>>
>> Subject: Re: 8 for 1.4
>>
>> I talked to the guys reworking the JS library for Drupal at Drupalcon
>> - they are also having to fork potentially around license as much as
>> anything else, since they'd like to distribute via drupal.org, which
>> means they were hoping to get the original author to re-license the
>> code to them as GPL.
>>
>> -Peter
>>
>> On Fri, Sep 25, 2009 at 4:45 PM, Grant Ingersoll 
>> wrote:
>>>
>>> Argh, this was meant for solr-dev.
>>>
>>> Begin forwarded message:
>>>
 From: Grant Ingersoll 
 Date: September 25, 2009 1:34:32 PM EDT
 To: solr-u...@lucene.apache.org
 Subject: 8 for 1.4
 Reply-To: solr-u...@lucene.apache.org

 Y'all,

 We're down to 8 open issues:

  https://issues.apache.org/jira/secure/BrowseVersion.jspa?id=12310230&versionId=12313351&showOpenIssuesOnly=true

 2 are packaging related, one is dependent on the official 2.9 release
 (so
 should be taken care of today or tomorrow I suspect) and then we have a
 few
 others.

 The only two somewhat major ones are S-1458, S-1294 (more on this in a
 mo') and S-1449.

 On S-1294, the SolrJS patch, I yet again have concerns about even
 including this, given the lack of activity (from Matthias, the original
 author and others) and the fact that some in the Drupal community have
 already forked this to fix the various bugs in it instead of just
 submitting
 patches.  While I really like the idea of this library (jQuery is
 awesome),
 I have yet to see interest in the community to maintain it (unless you
 count
 someone forking it and fixing the bugs in the fork as maintenance) and
 I'll
 be upfront in admitting I have neither the time nor the patience to
 debug
 Javascript across the gazillions of browsers out there (I don't even
 have IE
 on my machine unless you count firing up a VM w/ XP on it) in the wild.
  Given what I know of most of the other committers here, I suspect that
 is
 true for others too.  At a minimum, I think S-1294 should be pushed to
 1.5.
  Next up, I think we consider pulling SolrJS from the release, but
 keeping
 it in trunk and officially releasing it with either 1.5 or 1.4.1,
 assuming
 its gotten some love in the meantime.  If by then it has no love, I vote
 we
 remove it and let the fork maintain it and point people there.

 -Grant
>>>
>>>
>>>
>>
>>
>>
>> --
>> Peter M. Wolanin, Ph.D.
>> Momentum Specialist,  Acquia. Inc.
>> peter.wola...@acquia.com
>
> --
> Grant Ingersoll
> http://www.lucidimagination.com/
>
> Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids) using
> Solr/Lucene:
> http://www.lucidimagination.com/search
>
>

[jira] Assigned: (SOLR-1294) SolrJS/Javascript client fails in IE8!

[Ryan McKinley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan McKinley reassigned SOLR-1294:
---

Assignee: Ryan McKinley

> SolrJS/Javascript client fails in IE8!
> --
>
> Key: SOLR-1294
> URL: https://issues.apache.org/jira/browse/SOLR-1294
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Eric Pugh
>    Assignee: Ryan McKinley
> Fix For: 1.4
>
> Attachments: SOLR-1294-IE8.patch, SOLR-1294.patch, 
> solrjs-ie8-html-syntax-error.patch
>
>
> SolrJS seems to fail with "'jQuery.solrjs' is null or not an object" errors 
> under IE8.  I am continuing to test if this occurs in IE 6 and 7 as well.  
> This happens on both the Sample online site at 
> http://solrjs.solrstuff.org/test/reuters/ as well as the 
> /trunk/contrib/javascript library.   Seems to be a show stopper from the 
> standpoint of really using this library!
> I have posted a screenshot of the error at 
> http://img.skitch.com/20090717-jejm71u6ghf2dpn3mwrkarigwm.png
> The error is just a whole bunch of repeated messages in the vein of:
> Message: 'jQuery.solrjs' is null or not an object
> Line: 24
> Char: 1
> Code: 0
> URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/QueryItem.js
> Message: 'jQuery.solrjs' is null or not an object
> Line: 37
> Char: 1
> Code: 0
> URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/Manager.js
> Message: 'jQuery.solrjs' is null or not an object
> Line: 24
> Char: 1
> Code: 0
> URI: 
> file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/AbstractSelectionView.js
> Message: 'jQuery.solrjs' is null or not an object
> Line: 27
> Char: 1
> Code: 0
> URI: 
> file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/AbstractWidget.js

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Solr 1.4 Open Issues Status

[Ryan McKinley]

: SOLR-1294 SolrJS/Javascript client fails in IE8!  Unassigned
:
: > I have concerns about this client library being included at all  
in Solr, as
: > I don't see anyone taking it up for maintenance.  I raised  
concerns on the
: > main issue with no response and likewise with this one.  Patch  
exists.  Who

: > handled the original contribution?

Ryan did according to svn.

I'm elary of features in core that don'th ave a committer who is  
actively
involved with them, but i'm less concerend for client libraries --  
as long

as the community is submitting patches that can be tested, it's being
maintained.

I'd commit this patch, but i can't actualy test that it works (no  
access

to IE)


I'll take it...

 remembering a distant land where I had lots of time and energy  
for this stuff.  alas.

[jira] Resolved: (SOLR-1424) ant generate-maven-artifacts fails on windows

[Ryan McKinley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan McKinley resolved SOLR-1424.
-

   Resolution: Fixed
Fix Version/s: 1.4

> ant generate-maven-artifacts fails on windows
> -
>
> Key: SOLR-1424
> URL: https://issues.apache.org/jira/browse/SOLR-1424
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Ryan McKinley
> Fix For: 1.4
>
> Attachments: SOLR-1424.patch
>
>
> From solr-user...
> {noformat}
> generate-maven-artifacts:
> [mkdir] Created dir: c:\Downloads\solr_trunk\build\maven
> [mkdir] Created dir: c:\Downloads\solr_trunk\dist\maven
>  [copy] Copying 1 file to
> c:\Downloads\solr_trunk\build\maven\c:\Downloads\s
> olr_trunk\src\maven
> BUILD FAILED
> c:\Downloads\solr_trunk\build.xml:741: The following error occurred while
> execut
> ing this line:
> c:\Downloads\solr_trunk\common-build.xml:261: Failed to copy
> c:\Downloads\solr_t
> runk\src\maven\solr-parent-pom.xml.template to
> c:\Downloads\solr_trunk\build\mav
> en\c:\Downloads\solr_trunk\src\maven\solr-parent-pom.xml.template due to
> java.io
> .FileNotFoundException
> c:\Downloads\solr_trunk\build\maven\c:\Downloads\solr_tru
> nk\src\maven\solr-parent-pom.xml.template (The filename, directory name, or
> volu
> me label syntax is incorrect)
> {noformat}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-1424) ant generate-maven-artifacts fails on windows

[Ryan McKinley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan McKinley updated SOLR-1424:


Attachment: SOLR-1424.patch

> ant generate-maven-artifacts fails on windows
> -
>
> Key: SOLR-1424
> URL: https://issues.apache.org/jira/browse/SOLR-1424
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Ryan McKinley
> Fix For: 1.4
>
> Attachments: SOLR-1424.patch
>
>
> From solr-user...
> {noformat}
> generate-maven-artifacts:
> [mkdir] Created dir: c:\Downloads\solr_trunk\build\maven
> [mkdir] Created dir: c:\Downloads\solr_trunk\dist\maven
>  [copy] Copying 1 file to
> c:\Downloads\solr_trunk\build\maven\c:\Downloads\s
> olr_trunk\src\maven
> BUILD FAILED
> c:\Downloads\solr_trunk\build.xml:741: The following error occurred while
> execut
> ing this line:
> c:\Downloads\solr_trunk\common-build.xml:261: Failed to copy
> c:\Downloads\solr_t
> runk\src\maven\solr-parent-pom.xml.template to
> c:\Downloads\solr_trunk\build\mav
> en\c:\Downloads\solr_trunk\src\maven\solr-parent-pom.xml.template due to
> java.io
> .FileNotFoundException
> c:\Downloads\solr_trunk\build\maven\c:\Downloads\solr_tru
> nk\src\maven\solr-parent-pom.xml.template (The filename, directory name, or
> volu
> me label syntax is incorrect)
> {noformat}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (SOLR-1424) ant generate-maven-artifacts fails on windows

[Ryan McKinley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan McKinley reassigned SOLR-1424:
---

Assignee: Ryan McKinley

yup, that does it...  I will commit shortly

> ant generate-maven-artifacts fails on windows
> -
>
> Key: SOLR-1424
> URL: https://issues.apache.org/jira/browse/SOLR-1424
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Ryan McKinley
>
> From solr-user...
> {noformat}
> generate-maven-artifacts:
> [mkdir] Created dir: c:\Downloads\solr_trunk\build\maven
> [mkdir] Created dir: c:\Downloads\solr_trunk\dist\maven
>  [copy] Copying 1 file to
> c:\Downloads\solr_trunk\build\maven\c:\Downloads\s
> olr_trunk\src\maven
> BUILD FAILED
> c:\Downloads\solr_trunk\build.xml:741: The following error occurred while
> execut
> ing this line:
> c:\Downloads\solr_trunk\common-build.xml:261: Failed to copy
> c:\Downloads\solr_t
> runk\src\maven\solr-parent-pom.xml.template to
> c:\Downloads\solr_trunk\build\mav
> en\c:\Downloads\solr_trunk\src\maven\solr-parent-pom.xml.template due to
> java.io
> .FileNotFoundException
> c:\Downloads\solr_trunk\build\maven\c:\Downloads\solr_tru
> nk\src\maven\solr-parent-pom.xml.template (The filename, directory name, or
> volu
> me label syntax is incorrect)
> {noformat}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1424) ant generate-maven-artifacts fails on windows

[Ryan McKinley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754386#action_12754386
 ] 

Ryan McKinley commented on SOLR-1424:
-

no dice.  with:

{code}
$ svn diff
Index: common-build.xml
===
--- common-build.xml(revision 814053)
+++ common-build.xml(working copy)
@@ -104,13 +104,12 @@
   

   
-  
-  
+  
+  
+  

-  
-
{code}

I still get:
{code}
generate-maven-artifacts:
 [copy] Copying 1 file to 
c:\workspace\apache\solr\build\maven\c:\workspace\apache\solr\src\maven

BUILD FAILED
c:\workspace\apache\solr\build.xml:750: The following error occurred while 
executing this line:
c:\workspace\apache\solr\common-build.xml:260: Failed to copy 
c:\workspace\apache\solr\src\maven\solr-parent-pom.xml.template to 
c:\workspace\apache\solr\build\maven\c:\workspace\apache\solr\src\maven
\solr-parent-pom.xml.template due to java.io.FileNotFoundException 
c:\workspace\apache\solr\build\maven\c:\workspace\apache\solr\src\maven\solr-parent-pom.xml.template
 (The filename, directory name, o
r volume label syntax is incorrect)

Total time: 4 minutes 7 seconds
{code}

looking around at some other options, but don't see anything obvious

> ant generate-maven-artifacts fails on windows
> -
>
> Key: SOLR-1424
> URL: https://issues.apache.org/jira/browse/SOLR-1424
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>
> From solr-user...
> {noformat}
> generate-maven-artifacts:
> [mkdir] Created dir: c:\Downloads\solr_trunk\build\maven
> [mkdir] Created dir: c:\Downloads\solr_trunk\dist\maven
>  [copy] Copying 1 file to
> c:\Downloads\solr_trunk\build\maven\c:\Downloads\s
> olr_trunk\src\maven
> BUILD FAILED
> c:\Downloads\solr_trunk\build.xml:741: The following error occurred while
> execut
> ing this line:
> c:\Downloads\solr_trunk\common-build.xml:261: Failed to copy
> c:\Downloads\solr_t
> runk\src\maven\solr-parent-pom.xml.template to
> c:\Downloads\solr_trunk\build\mav
> en\c:\Downloads\solr_trunk\src\maven\solr-parent-pom.xml.template due to
> java.io
> .FileNotFoundException
> c:\Downloads\solr_trunk\build\maven\c:\Downloads\solr_tru
> nk\src\maven\solr-parent-pom.xml.template (The filename, directory name, or
> volu
> me label syntax is incorrect)
> {noformat}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Lucene RC2

[Ryan McKinley]

have not tried it yet but we should certainly upgrade.

the more testing the better!


On Aug 28, 2009, at 2:54 PM, Grant Ingersoll wrote:

Anyone tried out the new Lucene RC2 in Solr yet?  Should we upgrade  
to it?

Re: ant generate-maven-artifacts, BUILD FAILED?

[Ryan McKinley]

I only see the behavior on windows.  Works fine in linux/mac  (with  
same maven version)


Running with maven 2.2.1 I get the same results...

I'll try some more debugging tomorow


On Aug 25, 2009, at 11:41 AM, Grant Ingersoll wrote:




On Aug 25, 2009, at 11:17 AM, Grant Ingersoll wrote:


I'll take a look.  Have you tried a diff. version of Maven?

On Aug 24, 2009, at 3:09 PM, Ryan McKinley wrote:


Anyone else seeing this:
$ ant generate-maven-artifacts
...
...

BUILD FAILED
c:\workspace\apache\solr\build.xml:741: The following error occurred
while executing this line:
c:\workspace\apache\solr\common-build.xml:261: Failed to copy
c:\workspace\apache\solr\src\maven\solr-parent-pom.xml.template to
c:\workspace\apache\solr\build\maven\c:\workspace\apache\solr\src 
\maven\solr-parent-pom.xml.template

due to java.io.FileNotFoundException
c:\workspace\apache\solr\build\maven\c:\workspace\apache\solr\src 
\maven\solr-parent-pom.xml.template

(The filename, directory name, or volume label syntax is incorrect)

Total time: 3 minutes 37 seconds

$ ant -version
Apache Ant version 1.7.1 compiled on June 27 2008

$ mvn --version
Maven version: 2.0.10
Java version: 1.6.0_13
OS name: "windows vista" version: "6.0" arch: "amd64" Family:  
"windows"


- - - - - -

Obviously this has something to do with:
c:\workspace\apache\solr\build\maven\c:\workspace\apache...



Hmm, WFM (Works for me) but I'm on a Mac.

Does ant -diagnostics show anything weird?  You might try echoing  
out the basedir and the maven.build.dir


-Grant

[jira] Updated: (SOLR-1057) PathTokenizerFactory

[Ryan McKinley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-1057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan McKinley updated SOLR-1057:


Attachment: SOLR-1057-PathTokenizerFactory.patch

updated to use reusable token stuff

> PathTokenizerFactory
> 
>
> Key: SOLR-1057
> URL: https://issues.apache.org/jira/browse/SOLR-1057
> Project: Solr
>  Issue Type: New Feature
>  Components: Analysis
>Reporter: Ryan McKinley
>Priority: Minor
> Attachments: SOLR-1057-PathTokenizerFactory.patch, 
> SOLR-1057-PathTokenizerFactory.patch
>
>
> This is a Tokenizer that splits the input string into a series of paths.  For 
> example:
> {panel}
>  /aaa/bbb/ccc
> {panel}
> becomes:
> {panel}
>  /aaa/
>  /aaa/bbb/
>  /aaa/bbb/ccc
> {panel}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: /trunk ClassCastException with BaseTokenizerFactory

[Ryan McKinley]

not sure what you are asking for.

The patch in SOLR-1377 (now /trunk) breaks the TokenizerFactory API.

You will get an compiler error (or runtime error) with a  
TokenizerFactory that creates a TokenStream rather then a Tokenizer.


I don't see any clean way to do this via deprecation -- if you have  
ideas, shout them out.


ryan



On Aug 24, 2009, at 1:49 PM, Lance Norskog wrote:

Is it possible to mark out backwards-incompatible changes with  
deprecation?

So at least we get warnings in Eclipse/Netbeans etc?

On Fri, Aug 21, 2009 at 9:50 AM, Mark Miller   
wrote:



Ryan McKinley wrote:

Ahh, I see:
Tokenizer extends TokenStream

So if this is going to break everything that implements TokenStream
rather then Tokenizer, it seems we should change the  
TokenizerFactory

API from:
 public Tokenizer create( Reader input )
rather then:
 public TokenStream create( Reader input );

I would WAY rather have my compiler tell me something is wrong then
get an error and then find some documentation about the tokenizer.

- - - - -

Personally, I think lucene/solr just need to fess up and admit that
2.9 is *not* totally back compatible.

I don't think anyone contends that Lucene is totally backcompat - and
insofarasthatgoes there is no way Solr totally is - . it exposes a  
lot

of Lucene.

We admit our breaks in this release in the back compat breaks  
section.
There is no way we will release claiming total back compat. Not  
even in

the realm of possibility.

No way is the Multireader change back-compatible!


Personally, pure API wise - I think it was. Its a stickier issue on  
the

possible more RAM usage - but too me, thats more of a Runtime change.
Certain methods have always changed over time in their resource  
usage,

and I think thats within back compat. This was a steep one to swallow
though, I'll admit. Basically we just thought it was way worth it  
long
term. And Hoss came up with some great ideas to help ease the  
possible

pain.


ryan


On Aug 21, 2009, at 11:39 AM, Yonik Seeley wrote:


On Fri, Aug 21, 2009 at 10:13 AM, Ryan McKinley
wrote:
I'm fine upgrading, but it seems we should the 'back  
compatibility'

notice more explicit.


Yeah... that should be fun for expert-use plugins in general.  In
Lucene-land, this is the release of the "break"... I think we've
covered the changes reasonably well in our external APIs, but  
people

can always use pretty much the full Lucene API when writing Solr
plugins.

I think we'll need to document that things in  tags  
need to

inherit from Tokenizer classes.  It is technically a back-compat
break, but I assume it will affect very few users?

-Yonik
http://www.lucidimagination.com





--
- Mark

http://www.lucidimagination.com







--
Lance Norskog
goks...@gmail.com

ant generate-maven-artifacts, BUILD FAILED?

[Ryan McKinley]

Anyone else seeing this:
$ ant generate-maven-artifacts
...
...

BUILD FAILED
c:\workspace\apache\solr\build.xml:741: The following error occurred
while executing this line:
c:\workspace\apache\solr\common-build.xml:261: Failed to copy
c:\workspace\apache\solr\src\maven\solr-parent-pom.xml.template to
c:\workspace\apache\solr\build\maven\c:\workspace\apache\solr\src\maven\solr-parent-pom.xml.template
due to java.io.FileNotFoundException
c:\workspace\apache\solr\build\maven\c:\workspace\apache\solr\src\maven\solr-parent-pom.xml.template
(The filename, directory name, or volume label syntax is incorrect)

Total time: 3 minutes 37 seconds

$ ant -version
Apache Ant version 1.7.1 compiled on June 27 2008

$ mvn --version
Maven version: 2.0.10
Java version: 1.6.0_13
OS name: "windows vista" version: "6.0" arch: "amd64" Family: "windows"

- - - - - -

Obviously this has something to do with:
c:\workspace\apache\solr\build\maven\c:\workspace\apache...


thanks
ryan

[jira] Resolved: (SOLR-1377) Force TokenizerFactory to create a Tokenizer rather then TokenStream

[Ryan McKinley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-1377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan McKinley resolved SOLR-1377.
-

Resolution: Fixed

> Force TokenizerFactory to create a Tokenizer rather then TokenStream 
> -
>
> Key: SOLR-1377
> URL: https://issues.apache.org/jira/browse/SOLR-1377
> Project: Solr
>  Issue Type: New Feature
>  Components: Analysis
>Reporter: Ryan McKinley
>    Assignee: Ryan McKinley
> Fix For: 1.4
>
> Attachments: SOLR-1377-Tokenizer.patch, SOLR-1377.patch
>
>
> The new token reuse classes require that they are created with a Tokenizer.  
> The solr TokenizerFactory interface currently makes a TokenStream.
> Although this is an API breaking change, the alternative is to just document 
> that it needs to be a Tokenizer instance and throw an error when it is not.
> For more discussion, see:
> http://www.lucidimagination.com/search/document/272b8c4e6198d887/trunk_classcastexception_with_basetokenizerfactory

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1377) Force TokenizerFactory to create a Tokenizer rather then TokenStream

[Ryan McKinley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12747012#action_12747012
 ] 

Ryan McKinley commented on SOLR-1377:
-

Without objection... I will commit this soon

> Force TokenizerFactory to create a Tokenizer rather then TokenStream 
> -
>
> Key: SOLR-1377
> URL: https://issues.apache.org/jira/browse/SOLR-1377
> Project: Solr
>  Issue Type: New Feature
>  Components: Analysis
>Reporter: Ryan McKinley
>    Assignee: Ryan McKinley
> Fix For: 1.4
>
> Attachments: SOLR-1377-Tokenizer.patch, SOLR-1377.patch
>
>
> The new token reuse classes require that they are created with a Tokenizer.  
> The solr TokenizerFactory interface currently makes a TokenStream.
> Although this is an API breaking change, the alternative is to just document 
> that it needs to be a Tokenizer instance and throw an error when it is not.
> For more discussion, see:
> http://www.lucidimagination.com/search/document/272b8c4e6198d887/trunk_classcastexception_with_basetokenizerfactory

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1377) Force TokenizerFactory to create a Tokenizer rather then TokenStream

[Ryan McKinley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12746287#action_12746287
 ] 

Ryan McKinley commented on SOLR-1377:
-

Is reset gaurenteed to be called on the same Reader?  For the Pattern 
implementation, all the tokens are created beforehand and are just passed off 
with iter.next(), so if the input changes, the whole thing would need to change.

+   public void reset(Reader input) throws IOException {
+  super.reset(input);
+  init();
+   }

Any reason not to implement reset on: TrieTokenizerFactory?

> Force TokenizerFactory to create a Tokenizer rather then TokenStream 
> -
>
> Key: SOLR-1377
> URL: https://issues.apache.org/jira/browse/SOLR-1377
> Project: Solr
>  Issue Type: New Feature
>  Components: Analysis
>Reporter: Ryan McKinley
>    Assignee: Ryan McKinley
> Fix For: 1.4
>
> Attachments: SOLR-1377-Tokenizer.patch, SOLR-1377.patch
>
>
> The new token reuse classes require that they are created with a Tokenizer.  
> The solr TokenizerFactory interface currently makes a TokenStream.
> Although this is an API breaking change, the alternative is to just document 
> that it needs to be a Tokenizer instance and throw an error when it is not.
> For more discussion, see:
> http://www.lucidimagination.com/search/document/272b8c4e6198d887/trunk_classcastexception_with_basetokenizerfactory

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-1377) Force TokenizerFactory to create a Tokenizer rather then TokenStream

[Ryan McKinley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-1377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan McKinley updated SOLR-1377:


Attachment: SOLR-1377-Tokenizer.patch

Here is a patch that:

1. Changes the TokenizerFactory to return a Tokenizer
2. Updates all TokenizerFactory classes to explicitly return a Tokenizer
3. Changes the PatternTokenizerFactory to return a Tokenizer
4. adds a test that calls PatternTokenizer

- - -

Since this is an API breaking change, I added this to the "Upgrading from Solr 
1.3" section of CHANGES.txt:
{panel}
The TokenizerFactory API has changed to explicitly return a Tokenizer rather 
then
a TokenStream (that may be or may not be a Tokenizer).  This change is required
to take advantage of the Token reuse improvements in lucene 2.9.  For more 
information, see SOLR-1377. 
{panel}

I'll wait for two +1 votes on this, since it does break back compatibility


> Force TokenizerFactory to create a Tokenizer rather then TokenStream 
> -
>
> Key: SOLR-1377
> URL: https://issues.apache.org/jira/browse/SOLR-1377
> Project: Solr
>  Issue Type: New Feature
>  Components: Analysis
>Reporter: Ryan McKinley
>Assignee: Ryan McKinley
> Fix For: 1.4
>
> Attachments: SOLR-1377-Tokenizer.patch
>
>
> The new token reuse classes require that they are created with a Tokenizer.  
> The solr TokenizerFactory interface currently makes a TokenStream.
> Although this is an API breaking change, the alternative is to just document 
> that it needs to be a Tokenizer instance and throw an error when it is not.
> For more discussion, see:
> http://www.lucidimagination.com/search/document/272b8c4e6198d887/trunk_classcastexception_with_basetokenizerfactory

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (SOLR-1377) Force TokenizerFactory to create a Tokenizer rather then TokenStream

[Ryan McKinley (JIRA)]

Force TokenizerFactory to create a Tokenizer rather then TokenStream 
-

 Key: SOLR-1377
 URL: https://issues.apache.org/jira/browse/SOLR-1377
 Project: Solr
  Issue Type: New Feature
  Components: Analysis
Reporter: Ryan McKinley
Assignee: Ryan McKinley
 Fix For: 1.4


The new token reuse classes require that they are created with a Tokenizer.  
The solr TokenizerFactory interface currently makes a TokenStream.

Although this is an API breaking change, the alternative is to just document 
that it needs to be a Tokenizer instance and throw an error when it is not.

For more discussion, see:
http://www.lucidimagination.com/search/document/272b8c4e6198d887/trunk_classcastexception_with_basetokenizerfactory

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: /trunk ClassCastException with BaseTokenizerFactory

[Ryan McKinley]

Ahh, I see:
 Tokenizer extends TokenStream

So if this is going to break everything that implements TokenStream  
rather then Tokenizer, it seems we should change the TokenizerFactory  
API from:

  public Tokenizer create( Reader input )
rather then:
  public TokenStream create( Reader input );

I would WAY rather have my compiler tell me something is wrong then  
get an error and then find some documentation about the tokenizer.


- - - - -

Personally, I think lucene/solr just need to fess up and admit that  
2.9 is *not* totally back compatible.  No way is the Multireader  
change back-compatible!


ryan


On Aug 21, 2009, at 11:39 AM, Yonik Seeley wrote:

On Fri, Aug 21, 2009 at 10:13 AM, Ryan McKinley  
wrote:

I'm fine upgrading, but it seems we should the 'back compatibility'
notice more explicit.


Yeah... that should be fun for expert-use plugins in general.  In
Lucene-land, this is the release of the "break"... I think we've
covered the changes reasonably well in our external APIs, but people
can always use pretty much the full Lucene API when writing Solr
plugins.

I think we'll need to document that things in  tags need to
inherit from Tokenizer classes.  It is technically a back-compat
break, but I assume it will affect very few users?

-Yonik
http://www.lucidimagination.com

Re: /trunk ClassCastException with BaseTokenizerFactory

[Ryan McKinley]

On Aug 21, 2009, at 10:49 AM, Yonik Seeley wrote:

On Fri, Aug 21, 2009 at 10:33 AM, Ryan McKinley  
wrote:

Actually I think there may be something wrong here.

BaseTokenizerFactory does not make a Tokenizer, it creates a
TokenStream, so it should never be cast to Tokenizer

My custom TokenizerFactory now looks the same as:
o.a.s.analysis.PatternTokenizerFactory


Urg... looks like there's no end-to-end (index then search) test for
PatternTokenizerFactory, so we never caught this.


I guess we need to add one :)



It seems like when something is specified as a  in
schema.xml it should in fact be a tokenizer - it's the only way
tokenstream reuse works.



I don't see anything in Solr that creates a Tokenizer.  The  
TokenizerFactory just creates a TokenStream.


It seems that TokenizerFactory really needs to be:
  public Tokenizer create( Reader input )
rather then:
  public TokenStream create( Reader input );

I don't see any backwards compatible way to make this change!

ideas?
ryan

Re: /trunk ClassCastException with BaseTokenizerFactory

[Ryan McKinley]

Actually I think there may be something wrong here.

BaseTokenizerFactory does not make a Tokenizer, it creates a
TokenStream, so it should never be cast to Tokenizer

My custom TokenizerFactory now looks the same as:
o.a.s.analysis.PatternTokenizerFactory

Not sure what to look at next...  ideas?

thanks
ryan


On Fri, Aug 21, 2009 at 10:13 AM, Ryan McKinley wrote:
> Just updated to /trunk and am now seeing this exception:
>
> Caused by: org.apache.solr.client.solrj.SolrServerException:
> java.lang.ClassCastException:
> xxx.solr.analysis.JSONKeyValueTokenizerFactory$1 cannot be cast to
> org.apache.lucene.analysis.Tokenizer
>        at 
> org.apache.solr.client.solrj.embedded.EmbeddedSolrServer.request(EmbeddedSolrServer.java:141)
>        ... 15 more
> Caused by: java.lang.ClassCastException:
> xxx.solr.analysis.JSONKeyValueTokenizerFactory$1 cannot be cast to
> org.apache.lucene.analysis.Tokenizer
>        at 
> org.apache.solr.analysis.TokenizerChain.getStream(TokenizerChain.java:69)
>        at 
> org.apache.solr.analysis.SolrAnalyzer.reusableTokenStream(SolrAnalyzer.java:74)
>        at 
> org.apache.solr.schema.IndexSchema$SolrIndexAnalyzer.reusableTokenStream(IndexSchema.java:364)
>        at 
> org.apache.lucene.index.DocInverterPerField.processFields(DocInverterPerField.java:124)
>        at 
> org.apache.lucene.index.DocFieldProcessorPerThread.processDocument(DocFieldProcessorPerThread.java:244)
>        at 
> org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:772)
>
>
> Looks like SolrIndexAnalyzer now assumes everything uses the new
> TokenStream API...
>
> I'm fine upgrading, but it seems we should the 'back compatibility'
> notice more explicit.
>
>
> FYI, this is what the TokenizerFactory looks like:
>
> public class JSONKeyValueTokenizerFactory extends BaseTokenizerFactory
> {
>  ...
>
>  public TokenStream create(Reader input) {
>    final JSONParser js = new JSONParser( input );
>    final Stack keystack = new Stack();
>
>    return new TokenStream()
>    {
>      ...
>

/trunk ClassCastException with BaseTokenizerFactory

[Ryan McKinley]

Just updated to /trunk and am now seeing this exception:

Caused by: org.apache.solr.client.solrj.SolrServerException:
java.lang.ClassCastException:
xxx.solr.analysis.JSONKeyValueTokenizerFactory$1 cannot be cast to
org.apache.lucene.analysis.Tokenizer
at 
org.apache.solr.client.solrj.embedded.EmbeddedSolrServer.request(EmbeddedSolrServer.java:141)
... 15 more
Caused by: java.lang.ClassCastException:
xxx.solr.analysis.JSONKeyValueTokenizerFactory$1 cannot be cast to
org.apache.lucene.analysis.Tokenizer
at 
org.apache.solr.analysis.TokenizerChain.getStream(TokenizerChain.java:69)
at 
org.apache.solr.analysis.SolrAnalyzer.reusableTokenStream(SolrAnalyzer.java:74)
at 
org.apache.solr.schema.IndexSchema$SolrIndexAnalyzer.reusableTokenStream(IndexSchema.java:364)
at 
org.apache.lucene.index.DocInverterPerField.processFields(DocInverterPerField.java:124)
at 
org.apache.lucene.index.DocFieldProcessorPerThread.processDocument(DocFieldProcessorPerThread.java:244)
at 
org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:772)


Looks like SolrIndexAnalyzer now assumes everything uses the new
TokenStream API...

I'm fine upgrading, but it seems we should the 'back compatibility'
notice more explicit.


FYI, this is what the TokenizerFactory looks like:

public class JSONKeyValueTokenizerFactory extends BaseTokenizerFactory
{
  ...

  public TokenStream create(Reader input) {
final JSONParser js = new JSONParser( input );
final Stack keystack = new Stack();

return new TokenStream()
{
  ...

[jira] Updated: (SOLR-705) Distributed search should optionally return docID->shard map

[Ryan McKinley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan McKinley updated SOLR-705:
---

Fix Version/s: (was: 1.4)
   1.5

Moving this issue to 1.5 so that the details could be worked out with less 
haste.

http://www.lucidimagination.com/search/document/1f2e56f58162679d/response_writers_and_doclists

> Distributed search should optionally return docID->shard map
> 
>
> Key: SOLR-705
> URL: https://issues.apache.org/jira/browse/SOLR-705
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 1.3
> Environment: all
>Reporter: Brian Whitman
>Assignee: Ryan McKinley
> Fix For: 1.5
>
> Attachments: SOLR-705.patch, SOLR-705.patch, SOLR-705.patch, 
> SOLR-705.patch, SOLR-705.patch, SOLR-705.patch
>
>
> SOLR-303 queries with &shards parameters set need to return the dociD->shard 
> mapping in the response. Without it, updating/deleting documents when the # 
> of shards is variable is hard. We currently set this with a special 
> requestHandler that filters /update and inserts the shard as a field in the 
> index but it would be better if the shard location came back in the query 
> response outside of the index.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Response Writers and DocLists

[Ryan McKinley]

On Aug 18, 2009, at 10:01 AM, Grant Ingersoll wrote:



On Aug 18, 2009, at 9:49 AM, Ryan McKinley wrote:




Also, I'm thinking about having a real simple interface that  
would allow

for, when materializing the Fields, to pass in something like a
DocumentModifier, which would basically get the document right  
before it is
to be returned (possibly inside the SolrIndexReader, but maybe  
this even
belongs at the Lucene level similar to the FieldSelector,  
although it is
likely too late for 2.9.)  Through this DocModifier, one could  
easily add

fields, etc.


Too high level for Lucene I think, and nothing is currently needed  
for

Lucene - a user calls doc() to get the document and then they can
modify or add fields however they want.

An interface could be useful for Solr... but getting 1.4 out the  
door

is top priority.



Agreed... i am wondering if pushing:
https://issues.apache.org/jira/browse/SOLR-705
to 1.4 makes sense...


It already is marked for 1.4 and has been for a while.


dooh, i mean pushing it out of 1.4 (or into 1.5)

ryan

Re: Response Writers and DocLists

[Ryan McKinley]

Also, I'm thinking about having a real simple interface that would  
allow

for, when materializing the Fields, to pass in something like a
DocumentModifier, which would basically get the document right  
before it is
to be returned (possibly inside the SolrIndexReader, but maybe this  
even
belongs at the Lucene level similar to the FieldSelector, although  
it is
likely too late for 2.9.)  Through this DocModifier, one could  
easily add

fields, etc.


Too high level for Lucene I think, and nothing is currently needed for
Lucene - a user calls doc() to get the document and then they can
modify or add fields however they want.

An interface could be useful for Solr... but getting 1.4 out the door
is top priority.



Agreed... i am wondering if pushing:
https://issues.apache.org/jira/browse/SOLR-705
to 1.4 makes sense... since it should probably use the same interface/ 
strategy


ryan

Re: Response Writers and DocLists

[Ryan McKinley]

Ya, I like this idea.

Adding a "meta" field is OK, but it may just be kicking the can.  Also  
implementation wise, it works well when you have a SolrDocument, but  
when directly using DocList, it gets a bit messy.

https://issues.apache.org/jira/browse/SOLR-705

Also with adding a "meta" field, I'm not sure I like that it is a  
double object like:

 doc.get( "_meta_" ).get( "distance")

It would be nicer if the user does not have any idea if it is a pseudo- 
field or "real" field.  (by "user" I mean how you consume the  
response, not how you construct the URL)


The SQL "as" command comes to mind:
 SELECT name, count(xxx) as cnt

ryan



On Aug 17, 2009, at 6:00 PM, Grant Ingersoll wrote:

I'm looking a little bit at https://issues.apache.org/jira/browse/SOLR-1298 
 and some of the other "pseudo-field" capabilities and am curious  
how the various Response Writers are handling writing out the Docs.   
The XMLWriter seems to have a very different approach from the  
others when it comes to dealing with multi-valued fields (it sorts  
first, the others don't.)  Does anyone know the history here?


Also, I'm thinking about having a real simple interface that would  
allow for, when materializing the Fields, to pass in something like  
a DocumentModifier, which would basically get the document right  
before it is to be returned (possibly inside the SolrIndexReader,  
but maybe this even belongs at the Lucene level similar to the  
FieldSelector, although it is likely too late for 2.9.)  Through  
this DocModifier, one could easily add fields, etc.


Part of what I think needs to be addressed here is that currently,  
in order to add fields, for instance, LocalSolr does this, one needs  
to iterate over the DocList (or SolrDocList) multiple times.   
SolrPluginUtils.docListtoSolrDocList attempts to help, but it still  
requires a double loop.  The tricky part here is that one often  
needs to have context when modifying the Document that the Response  
Writer's simply do not have, so you end up writing a SearchComponent  
to do it and thus iterating multiple times.


I know this is a bit stream of conscience, but thought I would get  
it out there a little bit to see what others thought.


-Grant

[jira] Commented: (SOLR-705) Distributed search should optionally return docID->shard map

[Ryan McKinley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739076#action_12739076
 ] 

Ryan McKinley commented on SOLR-705:


I'll take this one on for 1.4...

I incorporate hoss' suggestion and then we can see how we like it.

> Distributed search should optionally return docID->shard map
> 
>
> Key: SOLR-705
> URL: https://issues.apache.org/jira/browse/SOLR-705
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 1.3
> Environment: all
>Reporter: Brian Whitman
>Assignee: Ryan McKinley
> Fix For: 1.4
>
> Attachments: SOLR-705.patch, SOLR-705.patch, SOLR-705.patch, 
> SOLR-705.patch, SOLR-705.patch, SOLR-705.patch
>
>
> SOLR-303 queries with &shards parameters set need to return the dociD->shard 
> mapping in the response. Without it, updating/deleting documents when the # 
> of shards is variable is hard. We currently set this with a special 
> requestHandler that filters /update and inserts the shard as a field in the 
> index but it would be better if the shard location came back in the query 
> response outside of the index.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (SOLR-705) Distributed search should optionally return docID->shard map

[Ryan McKinley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan McKinley reassigned SOLR-705:
--

Assignee: Ryan McKinley

> Distributed search should optionally return docID->shard map
> 
>
> Key: SOLR-705
> URL: https://issues.apache.org/jira/browse/SOLR-705
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 1.3
> Environment: all
>Reporter: Brian Whitman
>Assignee: Ryan McKinley
> Fix For: 1.4
>
> Attachments: SOLR-705.patch, SOLR-705.patch, SOLR-705.patch, 
> SOLR-705.patch, SOLR-705.patch, SOLR-705.patch
>
>
> SOLR-303 queries with &shards parameters set need to return the dociD->shard 
> mapping in the response. Without it, updating/deleting documents when the # 
> of shards is variable is hard. We currently set this with a special 
> requestHandler that filters /update and inserts the shard as a field in the 
> index but it would be better if the shard location came back in the query 
> response outside of the index.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.