Am 25.02.2010 um 02:07 schrieb Andy:
> 1) Built-in hierarchical faceting
> Right now there're 2 patches, SOLR-64 and SOLR-792. SOLR-64 seems to be
> slated for 1.5 release but according to the wiki seems to have poor
> performance. SOLR-792 has better performance according to the wiki but it's
Am 24.02.2010 um 14:42 schrieb Grant Ingersoll:
> What would it be?
Remote administration/editing/filling of synonyms.txt, stopwords.txt, ...
through a request handler, maybe a JSON interface or similar
best
Ingo
--
Ingo Renner
TYPO3 Core Developer, Release Manager TYPO3 4.2, Admin Google S
1. Real time or near-real time updates.
2. First-class spatial search.
On Wed, Feb 24, 2010 at 9:42 AM, Grant Ingersoll wrote:
> What would it be?
>
--
Jacob Elder
4/10, Teruhiko Kurosaka wrote:
>
>> From: Teruhiko Kurosaka
>> Subject: Re: If you could have one feature in Solr...
>> To: "solr-user@lucene.apache.org"
>> Date: Wednesday, March 24, 2010, 11:36 AM
>> (Sorry for very late response on this
>> topi
Right To Life,
otherwise we all die.
Read 'Hot, Flat, and Crowded'
Laugh at http://www.yert.com/film.php
--- On Wed, 3/24/10, Teruhiko Kurosaka wrote:
> From: Teruhiko Kurosaka
> Subject: Re: If you could have one feature in Solr...
> To: "solr-user@lucene.apache.org&
(Sorry for very late response on this topic.)
On Feb 28, 2010, at 5:47 AM, Adrien Specq wrote:
> - langage attribute for each field
I was thinking about it and it was one of my wishes.
Currently, Solr practically requires that we have
a field for each natural language that an application
support
On Fri, Mar 5, 2010 at 4:34 AM, Mark Miller wrote:
> On 03/04/2010 05:56 PM, Chris Hostetter wrote:
>>
>> : The ability to read solr configuration files from the classpath instead
>> of
>> : solr.solr.home directory.
>>
>> Solr has always supported this.
>>
>> When SolrResourceLoader.openResourceL
On 03/04/2010 05:56 PM, Chris Hostetter wrote:
: The ability to read solr configuration files from the classpath instead of
: solr.solr.home directory.
Solr has always supported this.
When SolrResourceLoader.openResourceLoader is asked to open a resource it
first checks if it's an absolute path
: The ability to read solr configuration files from the classpath instead of
: solr.solr.home directory.
Solr has always supported this.
When SolrResourceLoader.openResourceLoader is asked to open a resource it
first checks if it's an absolute path -- if it's not then it checks
relative the "
The ability to read solr configuration files from the classpath instead of
solr.solr.home directory.
Jorg
2010/3/1 Noble Paul നോബിള് नोब्ळ्
> On Wed, Feb 24, 2010 at 7:18 PM, Patrick Sauts
> wrote:
> > Synchronisation between the slaves to switch the new index at the same
> time
> > after rep
On Wed, Feb 24, 2010 at 7:18 PM, Patrick Sauts wrote:
> Synchronisation between the slaves to switch the new index at the same time
> after replication.
I shall open as issue for this. And let us figure out how best it should be done
https://issues.apache.org/jira/browse/SOLR-1800
On Feb 28, 2010, at 8:47 AM, Adrien Specq wrote:
- Built-in hierarchical faceting
Adrien - I'm curious what you mean by this exactly. Could you
describe your hierarchical faceting needs by example?Often
hierarchical faceting can be accomplished by simply indexing "/level1/
level2/...
On 2010-02-28 17:26, Ian Holsman wrote:
On 2/24/10 8:42 AM, Grant Ingersoll wrote:
What would it be?
most of this will be coming in 1.5,
but for me it's
- sharding.. it still seems a bit clunky
secondly.. this one isn't in 1.5.
I'd like to be able to find "interesting" terms that appear in m
On 2/24/10 8:42 AM, Grant Ingersoll wrote:
What would it be?
most of this will be coming in 1.5,
but for me it's
- sharding.. it still seems a bit clunky
secondly.. this one isn't in 1.5.
I'd like to be able to find "interesting" terms that appear in my result
set that don't appear in th
- Built-in hierarchical faceting
and
- langage attribute for each field
On Sat, Feb 27, 2010 at 9:59 PM, Stephen Weiss wrote:
> I think an examples page would be a good idea. We've already implemented
> search in Chinese, Japanese, and Spanish back with 1.3, but it was not
> really very well l
I think an examples page would be a good idea. We've already
implemented search in Chinese, Japanese, and Spanish back with 1.3,
but it was not really very well laid out how it was supposed to work -
I had to dig through bits and pieces of people's configs left in the
mailing list archives
Haha, superb! Have never noticed that before! That's made my day
Grant :-)
On 27 Feb 2010, at 12:13, "Grant Ingersoll" wrote:
>
> On Feb 26, 2010, at 11:28 PM, Dave Searle wrote:
>
>> To have a coffee waiting for me every morning when I wake up.
>> Marriage
>> material indeed.
>
>
> Dave,
>
On Feb 26, 2010, at 11:28 PM, Dave Searle wrote:
> To have a coffee waiting for me every morning when I wake up. Marriage
> material indeed.
Dave,
Didn't you know that one already exists?
http://localhost:8983/solr/admin/coffeehandler?type=ethiopian&cream=false&sugar=true&togo=true
:-)
-
To have a coffee waiting for me every morning when I wake up. Marriage
material indeed.
The indexer looking for an xml:lang attribute on text fields and using the
value to pick, tokeniser, dictionaries, etc, etc automatically (and knowing to
look for them in the standard places).
cheers
stuart
+1
I have several projects backburnered in the hope realtime search will
come to solr soon...
[m]
On Feb 26, 2010, at 8:37 PM, Don Werve wrote:
Realtime search, hands down.
Realtime search, hands down.
Error messages that make sense. I have to read the source far too
often when a simple change to errror-handling would make some feature
easy to use. If I want to read Java I'll use Lucene!
Passive-aggressive error handling is a related problem: when I do
something nonsensical I too often get "0 re
1. Spatial search
2. Ease of managing a sharded index, multi-server Solr instance.
I am aware these are in-progress, slated for Solr 1.5.
I may find myself getting involved on these shortly because I'm working on a
very large scale search project requiring both.
~ David
On Feb 24, 2010, at 8:4
Erik Hatcher wrote:
> Ron - I think SOLR-792 meets the need you describe. What do you think?
> It's "tree faceting", allowing you to facet down 2 levels deep
> arbitrarily on any two fields. Ideally we'd enhance it to be of
> arbitrary depth too.
Nice! It certainly handles my main use case.
Th
Ron - I think SOLR-792 meets the need you describe. What do you
think? It's "tree faceting", allowing you to facet down 2 levels deep
arbitrarily on any two fields. Ideally we'd enhance it to be of
arbitrary depth too.
Erik
On Feb 24, 2010, at 6:40 PM, Ron Mayer wrote:
Another
On Thu, 25 Feb 2010 13:06:03 -0500
Robert Muir wrote:
> Yeah, Thai and Arabic have the stuff in Solr 1.4
> For Chinese, if you want to do CJK bigram indexing, this is there
> too. If you want to do word-based "smart" indexing, you need to
> add an additional jar file to your classpath.
OK, but u
Yeah, Thai and Arabic have the stuff in Solr 1.4
For Chinese, if you want to do CJK bigram indexing, this is there too.
If you want to do word-based "smart" indexing, you need to add an additional
jar file to your classpath.
we can add a wiki page with examples of how to use these maybe to make it
I would like to be able to do a delta import on arbitrary data, not a
last modified date. Specifically, our database has an auto_increment
field called DID, or document identifier. For changes to existing data.
this field is updated anytime a row is changed in any way, effectively
turning it
On Thu, 25 Feb 2010 07:54:06 -0500
Robert Muir wrote:
> Gora, I wonder perhaps if there is a documentation issue.
>
> e.g. Thai, Arabic, Chinese were mentioned here previously, these
> are all supported, too.
>
> Let me know if you have any ideas!
Sorry, are you saying that these are available
Gora, I wonder perhaps if there is a documentation issue.
e.g. Thai, Arabic, Chinese were mentioned here previously, these are all
supported, too.
Let me know if you have any ideas!
On Thu, Feb 25, 2010 at 7:45 AM, Gora Mohanty wrote:
> On Thu, 25 Feb 2010 07:37:33 -0500
> Robert Muir wrote:
On Thu, 25 Feb 2010 07:37:33 -0500
Robert Muir wrote:
> Gora, have you tried the Hindi Analyzer in lucene? if you add it
> to lucene, the results exceed at least everything from FIRE 2008.
[...]
Oh! No, sorry, I haven't. So far, I have only looked at search
through Solr, and I guess I definitely
Gora, have you tried the Hindi Analyzer in lucene? if you add it to lucene,
the results exceed at least everything from FIRE 2008.
So I don't really understand where you are getting this information!
> Actually, the state of the art for NLP in Indian languages is
> quite poor, at least in the o
ot;
Paul Graham
"A mathematician is a device for turning coffee into theorems."
Paul Erdos (who obviously never met a sysadmin)
- Messaggio originale -
> Da: Grant Ingersoll
> A: solr-user@lucene.apache.org
> Inviato: Mer 24 febbraio 2010, 18:54:32
> Oggetto: Re: If
Real time search would be awesome.
-Matt
On Wed, 24 Feb 2010 15:49:15 +0100
Markus Jelsma wrote:
> Well, i don't have a specific request in mind. However, i can
> image a growing internet market for thai, chinese and arabic
> speaking people and the native languages on the african
> continent. Providing them with stemmers to handle plur
1) Built-in hierarchical faceting
Right now there're 2 patches, SOLR-64 and SOLR-792. SOLR-64 seems to be slated
for 1.5 release but according to the wiki seems to have poor performance.
SOLR-792 has better performance according to the wiki but it's unclear if it'll
ever be part of the Solr dist
with tips & tricks. For me the gold standard
of documentation is Django, the doc there is ridiculously good.
--- On Wed, 2/24/10, Grant Ingersoll wrote:
From: Grant Ingersoll
Subject: Re: If you could have one feature in Solr...
To: solr-user@lucene.apache.org
Date: Wednesday, February 24,
Grant Ingersoll wrote:
> What would it be?
* Run a MapReduce-likejob on all docs matching the results of a search?
I'm currently working on an app where I hope to be able to do
a query (hopefully using solr) and generate a map where every state
(or county or zip-code or school district or police
Chipping in
The wiki based nature of solr's documentation is rather different
compared to most payware and some open source products. However once
you get used to its "style" I found it quite adequate.
I also dawned on me that portions of Solr are advancing very quickly and
that the wiki styl
Grant,
One feature that I would like to see is the ability to do a Bitwise search
I have had to work around this with a Query Parser plugin that uses a
org.apache.lucene.search.Filter
I think having this feature would be very nice and I prefer it to searching
with multiple OR type queries especi
I actually found the documentation pretty great especially since (my
experience, anyway) most Java projects seem to default to generic
JavaDoc derived documentation (and that makes me cry).
That said, more cookbook-style "recipes" or stories would be helpful for
some of the more esoteric parts
On Feb 24, 2010, at 11:08 AM, Stefano Cherchi wrote:
> Decent documentation.
What parts do you feel are lacking? Or is it just across the board? Wikis are
both good and bad for documentation, IMO.
-Grant
Decent documentation.
S
--
"Anyone proposing to run Windows on servers should be prepared to explain
what they know about servers that Google, Yahoo, and Amazon don't."
Paul Graham
"A mathematician is a device for turning coffee into theorems."
Paul Erdos (wh
One additional feature within MoreLikeThis might be.. MoreLikeTHESE. This
would not be the same as querying multiple documents and fetching MoreLikeThis
documents for each individual result.
This would then actually only return MoreLikeThis documents based on multiple
documents.
Another colleg
Limit the number of results when the results are sorted.
In other words, if the results are sorted by name and there are 10,000
results, then there will be items of low relevancy mixed in with the
results and it is hard for the user to find the relevant ones. If I
could say, "give me no more than
Well, i don't have a specific request in mind. However, i can image a growing
internet market for thai, chinese and arabic speaking people and the native
languages on the african continent. Providing them with stemmers to handle
plurals etc. will allow for a better search experience.
Also, othe
A mature document processing pipeline, perhaps integration of
www.openpipeline.org which is Apache2.0 licensed
On Wed, Feb 24, 2010 at 9:22 AM, Markus Jelsma wrote:
>
> - stemmers for many more different languages
>
>
I don't want to hijack this thread, but i would like to know which languages
you are interested in!
--
Robert Muir
rcm...@gmail.com
- performing multiple queries at once, perhaps abusing HTTP POST. On some
application there is a page that executes five different queries. The HTTP
overhead is not that much of a problem but it would be a nice to have.
- retrieving documents per facet, not unlike the results from the MoreLikeTh
On Wed, Feb 24, 2010 at 8:42 AM, Grant Ingersoll wrote:
> What would it be?
>
Near real-time search & faceting.
--
Stephen Duncan Jr
www.stephenduncanjr.com
Synchronisation between the slaves to switch the new index at the same
time after replication.
Grant Ingersoll a écrit :
What would it be?
52 matches
Mail list logo
