Re: [jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr
Does Geohash enable range based queries? It's unclear from the wiki site. Can we do something like this http://code.google.com/apis/base/attrs-queries.html#LocDatQuer I would rather see SOLR go in the direction of being compatible with GData and GBase and invent more unique things, unless they are better somehow. GBase has a notation for doing function queries as well that we should build into SOLR, current SOLR function queries really are very non-intuitive for me and I spend a lot of time each time trying to figure out how to do them. Check this stuff out. http://code.google.com/apis/base/ranking-lang-spec.html#functions I'm not sure we need to create something quite this complex. However, I would like a way to do something like this without having to reboot the server. I personally thing this is best implemented using dynamic classloading. If people find that interesting, then we could look at scripting. I'm not a big fan of scripting because it's not object oriented, it's not maintainable, scripts always grow and get too complex to read so that when new people take a look at it the ramp up time is high. With dynamic classes, all of the functionality of what is available is there. No need to create new script functions, test them out, load them, fix bugs and all that. On Wed, Sep 17, 2008 at 7:01 PM, Ryan McKinley (JIRA) <[EMAIL PROTECTED]> wrote: > >[ > https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12631992#action_12631992 > ] > > Ryan McKinley commented on SOLR-773: > > > LocalLucene/Solr are currently designed to do exactly points 1-4. > > As for storing lat/lon in a single field... that sounds really interesting. > Currently the local lucene stuff uses two fields and > [NumberUtils.java|http://svn.apache.org/repos/asf/lucene/solr/trunk/src/java/org/apache/solr/util/NumberUtils.java] > to index/store the distance. It does a lot of good work to break various > bounding box levels into tokens and only performs math on the minimum result > set. > > We should consider a geohash field type: http://en.wikipedia.org/wiki/Geohash > to store lat/lon in a single string. This has some really interesting > features that are ideal for lucene. In particular, checking if a point is > within a bounding box is simply a lexicographic range query. > > Here is a public domain python geohash implementation: > http://mappinghacks.com/code/geohash.py.txt > >> Incorporate Local Lucene/Solr >> - >> >> Key: SOLR-773 >> URL: https://issues.apache.org/jira/browse/SOLR-773 >> Project: Solr >> Issue Type: New Feature >>Reporter: Grant Ingersoll >>Priority: Minor >> >> Local Lucene has been donated to the Lucene project. It has some Solr >> components, but we should evaluate how best to incorporate it into Solr. >> See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > >
Re: Distributed custom component
May be if I expand on it a bit ? Basically, I want localsolr to work with the latest trunk of the solr. And it seems to work just fine, but the distributed version doesn't work. Even though looking at the comments it seems the modes from solr-303 were planned to be moved to the latest code base(at least according to the localsolr author) I have modified access on those classes and member variables that were required to compile localsolr with the latest solr trunk. Now when I run the component it doesn't seem to call component's "process" function when I specify shards variable in the request query. So is any code from solr-303 going to merged with latest solr trunk? I saw a post about localsolr being donated to solr. So, my guess the two eventually are going to be compatible. But were any plans/decisions made for about now? Does anyone know why component's "process" is not being called when in distributed mode? Thanks outre wrote: > > Hi, > > I am fairly new to solr, but I realize that the question I am about to ask > is fairly large. > > Is there any way to create a custom component that would compile and run > with the latest solr src and would be capable of doing distributed search? > > I have looked at localsolr example and QueryComponent, created a similar > setup except for I was trying to compile with the latest code from svn. It > compiles fine but at run time I get access violation for > org/apache/solr/handler/component/ShardFieldSortedHitQueue. > > > -- View this message in context: http://www.nabble.com/Distributed-custom-component-tp19517853p19554163.html Sent from the Solr - Dev mailing list archive at Nabble.com.
Re: [jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr
On Sep 18, 2008, at 9:28 AM, Jason Rutherglen wrote: Does Geohash enable range based queries? It's unclear from the wiki site. yes -- if you munge the algorithm a bit, finding points within a region is a lexographic range query. This alteration was developed to support bounding box queries in big table. Big table does not let you perform multiple operations on multiple fields in a single query, so you have to figure out how to do it with one: http://labs.metacarta.com/blog/27.entry/geographic-queries-on-google-app-engine/ I have not worked with it yet, but it seem like it has some nice characteristics for lucene indexes Can we do something like this http://code.google.com/apis/base/attrs-queries.html#LocDatQuer I would rather see SOLR go in the direction of being compatible with GData and GBase and invent more unique things, unless they are better somehow. are you just talking about the query syntax? Yes, we should just use something that others are already doing...
Re: Distributed custom component
On Thu, Sep 18, 2008 at 7:57 PM, outre <[EMAIL PROTECTED]> wrote: > > So is any code from solr-303 going to merged with latest solr trunk? I'm not sure about your problem but SOLR-303 is already committed and has been released with Solr 1.3 > I saw a post about localsolr being donated to solr. So, my guess the two > eventually are going to be compatible. But were any plans/decisions made > for > about now? > Yes it has been donated to Lucene/Solr. You'll see progress in the coming weeks. See the following issues opened for this: https://issues.apache.org/jira/browse/LUCENE-1387 https://issues.apache.org/jira/browse/SOLR-773 -- Regards, Shalin Shekhar Mangar.
[jira] Resolved: (SOLR-560) Convert JDK logging to SLF4J
[ https://issues.apache.org/jira/browse/SOLR-560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley resolved SOLR-560. Resolution: Fixed Fix Version/s: 1.4 i'll close this for now... if we run into any issues we can re-open it or make a new issue > Convert JDK logging to SLF4J > > > Key: SOLR-560 > URL: https://issues.apache.org/jira/browse/SOLR-560 > Project: Solr > Issue Type: Wish >Reporter: Ryan McKinley >Assignee: Ryan McKinley > Fix For: 1.4 > > Attachments: slf4j-api-1.5.0.jar, slf4j-jdk14-1.5.0.jar, > SOLR-560-slf4j.patch, SOLR-560-slf4j.patch, SOLR-560-slf4j.patch, > SOLR-560-slf4j.patch > > > After lots of discussion, we should consider using SLF4j to enable more > flexibility in logging configuration. > See: > http://www.nabble.com/Solr-Logging-td16836646.html > http://www.nabble.com/logging-through-log4j-td13747253.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr
[ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632239#action_12632239 ] patrick o'leary commented on SOLR-773: -- Hey guys Placing both lat and long in the same field is good when used internally, the majority of users of localsolr have separate fields representing lat long, so make sure the representation does not effect the original document. WKT uses point as the naming convention for single item's and I'd suggest that rather than just str, it would also be nice to get to a KML wt format as well. I've done some stuff integrating in mapping components and KML goes down real well. However be aware as soon as you start supporting WKT, you will be asked for ERSI support, and poly support, ray tracing, collision and a lot more fun things :-) P > Incorporate Local Lucene/Solr > - > > Key: SOLR-773 > URL: https://issues.apache.org/jira/browse/SOLR-773 > Project: Solr > Issue Type: New Feature >Reporter: Grant Ingersoll >Priority: Minor > > Local Lucene has been donated to the Lucene project. It has some Solr > components, but we should evaluate how best to incorporate it into Solr. > See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-549) Enable configurable logging (jul or log4j)
[ https://issues.apache.org/jira/browse/SOLR-549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley resolved SOLR-549. Resolution: Duplicate Fix Version/s: 1.4 resolved with SOLR-560 > Enable configurable logging (jul or log4j) > -- > > Key: SOLR-549 > URL: https://issues.apache.org/jira/browse/SOLR-549 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Henri Biestro > Fix For: 1.4 > > Attachments: solr-log4j.patch, solr-log4j.patch, solr-log4j.patch > > > java.util.logging does not allow to easily create a self-sufficient 'war' > with respect to logging configuration. > The java.util.logging.LogManager used by the application is always created by > the container and is thus only configurable through the container; > furthermore, if one already uses say log4j in a webapp that embeds Solr, it > does not even seem possible to re-route jul logging into log4j just by > configuration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr
Too many acronyms in there. What is the WKT used for? Storing the data? The schema? I am confused by the wikipedia text about WKT. On Thu, Sep 18, 2008 at 11:08 AM, patrick o'leary (JIRA) <[EMAIL PROTECTED]> wrote: > >[ > https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632239#action_12632239 > ] > > patrick o'leary commented on SOLR-773: > -- > > Hey guys > > Placing both lat and long in the same field is good when used internally, the > majority of users > of localsolr have separate fields representing lat long, so make sure the > representation > does not effect the original document. > > WKT uses point as the naming convention for single item's and I'd suggest > that rather than just str, it would > also be nice to get to a KML wt format as well. I've done some stuff > integrating in mapping components and > KML goes down real well. > > However be aware as soon as you start supporting WKT, you will be asked for > ERSI support, and poly support, > ray tracing, collision and a lot more fun things :-) > > P > >> Incorporate Local Lucene/Solr >> - >> >> Key: SOLR-773 >> URL: https://issues.apache.org/jira/browse/SOLR-773 >> Project: Solr >> Issue Type: New Feature >>Reporter: Grant Ingersoll >>Priority: Minor >> >> Local Lucene has been donated to the Lucene project. It has some Solr >> components, but we should evaluate how best to incorporate it into Solr. >> See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > >
Re: [jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr
> Placing both lat and long in the same field is good when used internally The initial filtered range query should be much faster this way. Is it possible to then extract the lat and long out of the geohash for the narrowing portion? On Thu, Sep 18, 2008 at 11:08 AM, patrick o'leary (JIRA) <[EMAIL PROTECTED]> wrote: > >[ > https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632239#action_12632239 > ] > > patrick o'leary commented on SOLR-773: > -- > > Hey guys > > Placing both lat and long in the same field is good when used internally, the > majority of users > of localsolr have separate fields representing lat long, so make sure the > representation > does not effect the original document. > > WKT uses point as the naming convention for single item's and I'd suggest > that rather than just str, it would > also be nice to get to a KML wt format as well. I've done some stuff > integrating in mapping components and > KML goes down real well. > > However be aware as soon as you start supporting WKT, you will be asked for > ERSI support, and poly support, > ray tracing, collision and a lot more fun things :-) > > P > >> Incorporate Local Lucene/Solr >> - >> >> Key: SOLR-773 >> URL: https://issues.apache.org/jira/browse/SOLR-773 >> Project: Solr >> Issue Type: New Feature >>Reporter: Grant Ingersoll >>Priority: Minor >> >> Local Lucene has been donated to the Lucene project. It has some Solr >> components, but we should evaluate how best to incorporate it into Solr. >> See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > >
Re: [jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr
WKT is just a standard way to describe geometry. There *many* other options, but WKT is a simple text based one that is used in other gis databases, including mysql and PostGIS: http://dev.mysql.com/doc/refman/5.0/en/gis-wkt-format.html I'm not saying we *should* use it, just that we should keep it in mind. If we were able to have an arbitrary geometry type, WKT would be a good option to put in our xml documents to populate the data. POLYGON((0 0,10 0,10 10,0 10,0 0),(5 5,7 5,7 7,5 7, 5 5)) However, discussion of arbitrary shapes may be a ways off... for now if we get points and bounding boxes, i think we are in good shape :) On Sep 18, 2008, at 11:49 AM, Jason Rutherglen wrote: Too many acronyms in there. What is the WKT used for? Storing the data? The schema? I am confused by the wikipedia text about WKT. On Thu, Sep 18, 2008 at 11:08 AM, patrick o'leary (JIRA) <[EMAIL PROTECTED]> wrote: [ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632239 #action_12632239 ] patrick o'leary commented on SOLR-773: -- Hey guys Placing both lat and long in the same field is good when used internally, the majority of users of localsolr have separate fields representing lat long, so make sure the representation does not effect the original document. WKT uses point as the naming convention for single item's and I'd suggest that rather than just str, it would also be nice to get to a KML wt format as well. I've done some stuff integrating in mapping components and KML goes down real well. However be aware as soon as you start supporting WKT, you will be asked for ERSI support, and poly support, ray tracing, collision and a lot more fun things :-) P Incorporate Local Lucene/Solr - Key: SOLR-773 URL: https://issues.apache.org/jira/browse/SOLR-773 Project: Solr Issue Type: New Feature Reporter: Grant Ingersoll Priority: Minor Local Lucene has been donated to the Lucene project. It has some Solr components, but we should evaluate how best to incorporate it into Solr. See http://lucene.markmail.org/message/orzro22sqdj3wows? q=LocalLucene -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr
On Sep 18, 2008, at 11:53 AM, Jason Rutherglen wrote: Placing both lat and long in the same field is good when used internally The initial filtered range query should be much faster this way. Is it possible to then extract the lat and long out of the geohash for the narrowing portion? correct -- depending on the hash length, you get greater precision. With a 10 character long hash, you get 2 foot precision. I'm not sure how we would do the implementation details, but I'm imagining the stored value would (could) be the exact input string and an analyzer generates geohash token. and maybe stores the exact location as payload. Then a location query would do a range query on the proper geohash, and then if necessary do real math on the exact locations -- either from a payload or stored field...
[jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr
[ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632284#action_12632284 ] Ryan McKinley commented on SOLR-773: I'm looking over the code grant now... (thanks again!) There are two implementations of LocalUpdateProcessorFactory: com.mapquest com.pjaol They do slightly different things... * The pjaol version creates a CartesianTierPlotter and then builds a bunch of fields for each level: _localTierN * The mapquest verison puts a bunch of spatial tokens (sid/SpatialIndex) into a single field. Any pointers on why one approach over the other? Do they solve the same problem? The mapquest version seems like it could be easily replaced with an Analyzer... perhaps one that takes a single lat/lon string: 12.345 -67.89 and then generates tokens for it. All the plumbing to encode the data in an updateProcessor then decode it in a FieldType seems a bit awkward. > Incorporate Local Lucene/Solr > - > > Key: SOLR-773 > URL: https://issues.apache.org/jira/browse/SOLR-773 > Project: Solr > Issue Type: New Feature >Reporter: Grant Ingersoll >Priority: Minor > > Local Lucene has been donated to the Lucene project. It has some Solr > components, but we should evaluate how best to incorporate it into Solr. > See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr
[ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632327#action_12632327 ] patrick o'leary commented on SOLR-773: -- I believe you guys are using a branch of the code as we were looking at using the mapquest sids. Both versions are solving the same basic problem, creating a sudo quad tree implementation. com.pjaol was the initial API I built, com.mapquest is donated to us by MapQuest. Both versions work by flattening out the earth onto a series of grids, the grids get progressively smaller with each _localTierN, in the MapQuest version there is a notion of zooming. Some quick info graphics here: http://www.nsshutdown.com/projects/lucene/whitepaper/locallucene_v2.html The differences are, com.pjaol uses pretty exact measurements, the flattening method is based on something called a sinusoidal projection, where I translate lat / longs to x,y coordinates which provide an equal spaced projection on a flat surface. Then I use GeoTools for the actual precise distance calculation. It comes at a slight performance cost to be that exact, but users have a need for it. The com.mapquest code, does a direct conversion to cartesian x,y coordinate from lat / long, encodes and generates sids and uses a standard great circle equation for distance calculation. So not as convoluted. It does come at a slight accuracy cost - but only in a few places, Greenland, New Zealand, some places around the poles and equator. So it's perfect for web based applications as the +/- error differential is small enough to be acceptable for most users. There is however a good audience for local lucene, who use it for more exact calculation, even down to the meter range. It's also used by some research groups for non-land based activities hence the desire to retain the exactness. > Incorporate Local Lucene/Solr > - > > Key: SOLR-773 > URL: https://issues.apache.org/jira/browse/SOLR-773 > Project: Solr > Issue Type: New Feature >Reporter: Grant Ingersoll >Priority: Minor > > Local Lucene has been donated to the Lucene project. It has some Solr > components, but we should evaluate how best to incorporate it into Solr. > See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-776) Maven Artifacts need to be signed.
Maven Artifacts need to be signed. -- Key: SOLR-776 URL: https://issues.apache.org/jira/browse/SOLR-776 Project: Solr Issue Type: Bug Affects Versions: 1.3 Reporter: Grant Ingersoll Assignee: Grant Ingersoll Fix For: 1.3.1 Released Maven artifacts need to be signed just like any other artifact. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Distributed custom component
Seems like my problem could be that qt parameter is not passed.
I see it in the createMainQuery and then after it in SolrCore execute params
do not have qt in there.
It appears that in SearchHandle:
String shardHandler = req.getParams().get(ShardParams.SHARDS_QT);
if (shardHandler == null) {
params.remove(CommonParams.QT);
} else {
params.set(CommonParams.QT, shardHandler);
}
Where ShardParams.SHARDS_QT = "shards.qt".
Should I change qt shards.qt then? Or is there another way?
Thanks
outre wrote:
>
> Hi,
>
> I am fairly new to solr, but I realize that the question I am about to ask
> is fairly large.
>
> Is there any way to create a custom component that would compile and run
> with the latest solr src and would be capable of doing distributed search?
>
> I have looked at localsolr example and QueryComponent, created a similar
> setup except for I was trying to compile with the latest code from svn. It
> compiles fine but at run time I get access violation for
> org/apache/solr/handler/component/ShardFieldSortedHitQueue.
>
>
>
--
View this message in context:
http://www.nabble.com/Distributed-custom-component-tp19517853p19559544.html
Sent from the Solr - Dev mailing list archive at Nabble.com.
[jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr
[ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632356#action_12632356 ] Ryan McKinley commented on SOLR-773: Thanks for the clarification... > > Then I use GeoTools for the actual precise distance calculation. > FYI, in the initial apache checking, I'm removing the GeoTools dependancy (it is LGPL) I'd like to make the distanceHandler logic for distance calculations pluggable so its easy to link to GeoTools when necessary. > Incorporate Local Lucene/Solr > - > > Key: SOLR-773 > URL: https://issues.apache.org/jira/browse/SOLR-773 > Project: Solr > Issue Type: New Feature >Reporter: Grant Ingersoll >Priority: Minor > > Local Lucene has been donated to the Lucene project. It has some Solr > components, but we should evaluate how best to incorporate it into Solr. > See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr
[ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632358#action_12632358 ] patrick o'leary commented on SOLR-773: -- Yep agree > Incorporate Local Lucene/Solr > - > > Key: SOLR-773 > URL: https://issues.apache.org/jira/browse/SOLR-773 > Project: Solr > Issue Type: New Feature >Reporter: Grant Ingersoll >Priority: Minor > > Local Lucene has been donated to the Lucene project. It has some Solr > components, but we should evaluate how best to incorporate it into Solr. > See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-776) Maven Artifacts need to be signed.
[ https://issues.apache.org/jira/browse/SOLR-776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll updated SOLR-776: - Attachment: SOLR-776.patch Here's a first crack at this. The only thing I don't like is that I have to paste in the passphrase every single time gpg is called. I try to get around this by asking for it up front and then putting it into a file and using the file as the std-in on the exec command, but that doesn't work on my machine (OS X), so I'd really appreciate the help. If all else fails, we just need to cut-n-paste it in for every jar. > Maven Artifacts need to be signed. > -- > > Key: SOLR-776 > URL: https://issues.apache.org/jira/browse/SOLR-776 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll > Fix For: 1.3.1 > > Attachments: SOLR-776.patch > > > Released Maven artifacts need to be signed just like any other artifact. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Distributed custom component
Here is what I got so far.
I can add shard.qt parameter to the query string along with shards and qt,
then distributed version of my component is working.
Otherwise "process" function in my custom component is not called, only
default SolrCore "execute".
It seems like a hacky approach to the problem though, I am wondering if
there is better solution.
Thanks
outre wrote:
>
> Seems like my problem could be that qt parameter is not passed.
>
> I see it in the createMainQuery and then after it in SolrCore execute
> params do not have qt in there.
>
> It appears that in SearchHandle:
>
> String shardHandler = req.getParams().get(ShardParams.SHARDS_QT);
> if (shardHandler == null) {
>params.remove(CommonParams.QT);
> } else {
>params.set(CommonParams.QT, shardHandler);
> }
>
> Where ShardParams.SHARDS_QT = "shards.qt".
>
> Should I change qt shards.qt then? Or is there another way?
>
>
> Thanks
>
>
> outre wrote:
>>
>> Hi,
>>
>> I am fairly new to solr, but I realize that the question I am about to
>> ask is fairly large.
>>
>> Is there any way to create a custom component that would compile and run
>> with the latest solr src and would be capable of doing distributed
>> search?
>>
>> I have looked at localsolr example and QueryComponent, created a similar
>> setup except for I was trying to compile with the latest code from svn.
>> It compiles fine but at run time I get access violation for
>> org/apache/solr/handler/component/ShardFieldSortedHitQueue.
>>
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/Distributed-custom-component-tp19517853p19562451.html
Sent from the Solr - Dev mailing list archive at Nabble.com.
[jira] Created: (SOLR-777) backword match search, for domain search etc.
backword match search, for domain search etc. - Key: SOLR-777 URL: https://issues.apache.org/jira/browse/SOLR-777 Project: Solr Issue Type: New Feature Components: search Affects Versions: 1.3 Reporter: Koji Sekiguchi Priority: Minor There is a requirement for searching domains with backward match. For example, using "apache.org" for a query string, www.apache.org, lucene.apache.org could be returned. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-777) backword match search, for domain search etc.
[ https://issues.apache.org/jira/browse/SOLR-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632489#action_12632489 ] Walter Underwood commented on SOLR-777: --- You don't need backwards matching for this, and it doesn't really do the right thing. Split the string on ".", reverse the list, and join successive sublists with ".". Don't index the length one list, since that is ".com", ".net", etc. Do the same processing at query time. This is a special analyzer. > backword match search, for domain search etc. > - > > Key: SOLR-777 > URL: https://issues.apache.org/jira/browse/SOLR-777 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.3 >Reporter: Koji Sekiguchi >Priority: Minor > > There is a requirement for searching domains with backward match. For > example, using "apache.org" for a query string, www.apache.org, > lucene.apache.org could be returned. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-777) backword match search, for domain search etc.
[
https://issues.apache.org/jira/browse/SOLR-777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koji Sekiguchi updated SOLR-777:
Attachment: SOLR-777-reverseStringFilter.patch
ReverseStringFilter and its factory class to reverse token string. To use this,
define schema.xml:
{code:xml}
:
{code}
and use analysis.jsp to see what happen.
TODO:
* consider the posibilities of getting PrefixQuery. for instance,
q=domain:apache.org => PrefixQuery( Term( "domain", "gro.ehcapa" ) )
* JUnit test code for this TokenFilter
> backword match search, for domain search etc.
> -
>
> Key: SOLR-777
> URL: https://issues.apache.org/jira/browse/SOLR-777
> Project: Solr
> Issue Type: New Feature
> Components: search
>Affects Versions: 1.3
>Reporter: Koji Sekiguchi
>Priority: Minor
> Attachments: SOLR-777-reverseStringFilter.patch
>
>
> There is a requirement for searching domains with backward match. For
> example, using "apache.org" for a query string, www.apache.org,
> lucene.apache.org could be returned.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-777) backword match search, for domain search etc.
[ https://issues.apache.org/jira/browse/SOLR-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632491#action_12632491 ] Koji Sekiguchi commented on SOLR-777: - Walter, The domain example is a just example for explanation. I think there are requirements for backward match in general. I'm thinking something like ReverseStrField which reverses token string when indexing and query. And if possible, q=domain:apache.org makes PrefixQuery( Term( "domain", "gro.ehcapa" ) ). What do you think? > backword match search, for domain search etc. > - > > Key: SOLR-777 > URL: https://issues.apache.org/jira/browse/SOLR-777 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.3 >Reporter: Koji Sekiguchi >Priority: Minor > Attachments: SOLR-777-reverseStringFilter.patch > > > There is a requirement for searching domains with backward match. For > example, using "apache.org" for a query string, www.apache.org, > lucene.apache.org could be returned. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-778) Wrong parameter name in SolrQuery#getFacetMinCount().
Wrong parameter name in SolrQuery#getFacetMinCount(). - Key: SOLR-778 URL: https://issues.apache.org/jira/browse/SOLR-778 Project: Solr Issue Type: Bug Components: clients - java Affects Versions: 1.3 Reporter: Kohei Taketa Priority: Minor SolrQuery#getFacetMinCount() should get a parameter value of FacetParams.FACET_MINCOUNT, but it actually gets a value of FacetParams.FACET_LIMIT. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-778) Wrong parameter name in SolrQuery#getFacetMinCount().
[ https://issues.apache.org/jira/browse/SOLR-778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar resolved SOLR-778. Resolution: Fixed Fix Version/s: 1.3.1 Assignee: Shalin Shekhar Mangar Committed revision 696926. Thanks Kohei! > Wrong parameter name in SolrQuery#getFacetMinCount(). > - > > Key: SOLR-778 > URL: https://issues.apache.org/jira/browse/SOLR-778 > Project: Solr > Issue Type: Bug > Components: clients - java >Affects Versions: 1.3 >Reporter: Kohei Taketa >Assignee: Shalin Shekhar Mangar >Priority: Minor > Fix For: 1.3.1 > > > SolrQuery#getFacetMinCount() should get a parameter value of > FacetParams.FACET_MINCOUNT, but it actually gets a value of > FacetParams.FACET_LIMIT. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
