(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/Lengt
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 requir
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 docum
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, Stev
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
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 pl
>
> 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 go
>
> 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
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
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 reall
[
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 s
[
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 incl
[
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
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 mi
[
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
[
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
[
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 u
[
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
[
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
[
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 funct
[
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
[
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
[
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 implementi
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
[
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
[
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 upd
[
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
[
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
[
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
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": "w
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 col
[
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
[
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 compatibi
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
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.
[
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 != HttpRequestExcep
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 an
[
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
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: functio
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
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
+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
wrot
+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 See
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)
a
+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
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 f
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
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 p
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
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 proble
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 sh
[
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.
[
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.
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
[
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 w
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
Looks like we are down to zero issues:
https://issues.apache.org/jira/secure/BrowseVersion.jspa?id=12310230&versionId=12313351&showOpenIssuesOnly=true
[
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
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
[
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 Sol
[
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 g
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
[
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/Jav
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 attent
[
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:1
[
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, i
[
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, th
[
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...
[
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
[
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
: 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
[
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
rage 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 gi
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 re
[
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
: 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. Patc
[
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 wind
[
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 wind
[
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-ma
[
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: co
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?
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:
[
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
f 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 McK
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
[
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 TokenStr
[
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
[
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
[
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
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
-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.
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
... 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 ca
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.embed
[
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
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 basicall
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
bel
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,
[
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 in
[
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->sha
1 - 100 of 1806 matches
Mail list logo
