Nutch is a Lucene sub-project, and it uses org.apache.nutch, not
org.apache.lucene.nutch.
I'd follow that for consistency's sake, until we see a problem.
Otis
- Original Message
From: Yonik Seeley [EMAIL PROTECTED]
To: solr-dev@lucene.apache.org
Cc: solr-commits@lucene.apache.org
Sent:
Wow, thanks for taking the time to figure this out, Yonik. The c renders
correctly for me, but even if it doesn't, don't worry about it, unless you
really want to fix the Forrest/httpd conf encodings...
Otis
- Original Message
From: Yonik Seeley [EMAIL PROTECTED]
To:
+1!
Jetty would be better than Tomcat. Tomcat is a bear compared to Jetty.
Otis
- Original Message
From: Yonik Seeley [EMAIL PROTECTED]
To: solr-dev@lucene.apache.org
Sent: Tue 14 Feb 2006 10:39:35 AM EST
Subject: tutorial or demo download
What do people think about a downloadable
Hi,
How far is Solr from what Hoss described below - single solr.war with multiple
instances/collections/indices?
I know it has been discussed in the past, but I don't recall anything after
that.
Thanks,
Otis
- Original Message
From: Chris Hostetter [EMAIL PROTECTED]
To:
Grab the code from Lucene in Action, it's got something to get you going, see:
http://www.lucenebook.com/search?query=metaphone
Otis
- Original Message
From: Chris Hostetter [EMAIL PROTECTED]
To: solr-dev@lucene.apache.org
Sent: Tuesday, November 7, 2006 6:04:02 PM
Subject: Re:
Doesn't this bulk upload sound a bit like Simon's GData server? That, too,
uses APP, I believe.
Otis
- Original Message
From: Walter Underwood [EMAIL PROTECTED]
To: solr-dev@lucene.apache.org
Sent: Tuesday, November 7, 2006 2:36:37 PM
Subject: Re: [jira] Commented: (SOLR-66) bulk data
Bertrand, please keep SOLR-58 in mind. I'm nearly finished with it. If you
decide to make changes to the structure of admin pages, please do it within
SOLR-58, so we avoid collision. There is some XSLT there already.
Otis
- Original Message
From: Bertrand Delacretaz [EMAIL
Hi,
I'd like to finalize and commit SOLR-58 in the next few days. Please review.
I've written XSLT stylesheets assuming the XML that the new JSPs return is OK
by everyone.
Thanks,
Otiz
P.S.
Wunder - http://www.cafeconleche.org/books/bible3/chapters/ch15.html was
invaluable,
Hi,
As I'm adding NGramTokenizer and other things to my local schema.xml for
development, I'm wondering where the new tokenizer/fieldtype/copyField should
really go? In other words, which schema.xml instance should I add them to
before making a diff/patch?
$ ff schema.xml
+1
Otis
- Original Message
From: Yonik Seeley [EMAIL PROTECTED]
To: solr-dev@lucene.apache.org
Sent: Thursday, January 4, 2007 3:29:36 PM
Subject: [VOTE] graduate Solr to Lucene subproject
It's time that Solr graduate from the incubator and become an official
Lucene subproject.
So,
Hi,
Are there existing practices for giving credit to companies that sponsor
development of Solr (or Nutch or Lucene or ...) by paying
consultants/developers to work on Solr (or Nutch or ...) and contribute their
work back to ASF?
If there are no existing practices, any suggestions? The
loading can be enabled via a solrconfig directive.
This will be faster when
not all stored fields are needed from a document (klaas, SOLR-52)
+10. Made admin JSPs return XML and transform them with new XSL
stylesheets
+(Otis Gospodnetic, SOLR-58)
Optimizations
1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simpy -- http://www.simpy.com/ - Tag - Search - Share
- Original Message
From: Otis Gospodnetic [EMAIL PROTECTED]
To: solr-dev@lucene.apache.org
Sent: Thursday, February 15, 2007 2:21:18 AM
Subject: Re: finer granularity of configuration
Or are you after having multiple
Hi,
- Original Message
From: Yonik Seeley [EMAIL PROTECTED]
On 2/15/07, Otis Gospodnetic [EMAIL PROTECTED] wrote:
Sorry, this was meant for Erik (relates to some direct emails). Now everyone
knows my secret desire: 1 Solr to serve N indices with the same config, just
a different
Hi,
I'm still torturing SOLR-81 - the spellchecker fronted with a Solr
RequestHandler.
Being a RequestHandler virgin, I'm not sure how to go from getting the
alternative
spelling suggestion(s) in the RequestHandler, to the output that might look
something
like this (made it up on the
Hi,
- Original Message
From: Erik Hatcher [EMAIL PROTECTED]
To: solr-dev@lucene.apache.org
Sent: Friday, March 16, 2007 4:36:25 PM
Subject: Re: svn commit: r519107 - in /lucene/solr/trunk: CHANGES.txt
example/exampledocs/spellchecher.xml example/solr/conf/solrconfig.xml
Yeah, I like that version of the logo best. If 1.2 is happening, I'd say it's
time to start using that logo or some similar variation on the theme.
Otis
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simpy -- http://www.simpy.com/ - Tag - Search - Share
- Original
Spotted this while looking at QueryResultKey class:
final Sort sort; // change to normal Sort after Lucene 1.4.3
Not sure what it refers to, but since it doesn't have a FIXME nor TODO, it may
be hard to catch this, and since we are on Lucene 2.*, maybe this can be
changed now -- I'm not sure
Hi,
I *think* the practise is to just resolve issues as Fixed when their patches
are committed. I believe we can then close them after the release containing
that fix has been released. That said, I know I rarely actually close JIRA
issues after releases over in Lucene-java.
Otis
. . . . .
[EMAIL PROTECTED]
To: solr-dev@lucene.apache.org
Sent: Monday, April 30, 2007 12:16:49 AM
Subject: Re: On Closing JIRA issues
Otis Gospodnetic wrote:
Hi,
I *think* the practise is to just resolve issues as Fixed when their patches
are committed. I believe we can then close them after
I'm about to put Solr in Jetty 6.1.2 and can report the results next week.
Generally speaking, I'd be for trying 6.1.2, as I've been watching their bug
reports and I see they've slowed down a lot.
Otis
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simpy -- http://www.simpy.com/
Emmanuel,
This sounds useful!
Here is everything you'll need to know:
http://wiki.apache.org/solr/HowToContribute
Thanks,
Otis
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simpy -- http://www.simpy.com/ - Tag - Search - Share
- Original Message
From: Emmanuel
I haven't moved to 6.* yet. But I did notice 6.1.3 showed up a few days ago.
Otis
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simpy -- http://www.simpy.com/ - Tag - Search - Share
- Original Message
From: Yonik Seeley [EMAIL PROTECTED]
To:
Hi,
Touchy topic: code style
Should Solr be following the Lucene code formatting/style? Lucene follows
Sun's recommendation except for the 2-space indent, I believe. I'm asking
because Solr is full of variable and method names that look like abbrevs ;) -
e.g. getDocListC - C?, and on top of
Hi,
- Original Message
From: Yonik Seeley [EMAIL PROTECTED]
To: solr-dev@lucene.apache.org
Sent: Thursday, May 17, 2007 2:05:41 PM
Subject: Re: Code style
On 5/17/07, Otis Gospodnetic [EMAIL PROTECTED] wrote:
Should Solr be following the Lucene code formatting/style
Hi,
- Original Message
From: Chris Hostetter [EMAIL PROTECTED]
I'd certianly prefer if all new code and new changes met teh style
guidelines we have setup -- tidying up the lines that are being changed
anyway as part of the commit, but frankly i'd just as soon leave code that
works but
+1 to sharing styles. Next week, I'll see if I can get my Eclipse 3.2 style
that I customized to fit Lucene style.
Otis
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simpy -- http://www.simpy.com/ - Tag - Search - Share
- Original Message
From: Chris Hostetter
I'd slap versions to those 2 XSL files to immediately answer which version of
Atom|RSS does this produce?
Otis
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simpy -- http://www.simpy.com/ - Tag - Search - Share
- Original Message
From: [EMAIL PROTECTED] [EMAIL
Ian - stats and charts make me drool, so +1 to a patch that provides that. The
3 links you gave don't seem to have any data right now.
Otis
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simpy -- http://www.simpy.com/ - Tag - Search - Share
- Original Message
From:
Here is a big +1 for the functionality that Henri added via SOLR-215! The last
patch I looked was big-ish, but didn't look too difficult.
The best way to avoid having to keep the patch up to date is to. commit it
:)
Otis
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simpy
Yes, I think I mentioned the same thing in one of my comments, I think in
SOLR-255. Smaller == easier to understand == less potential breakage ==
less risk to commit == commit! :)
Otis
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simpy -- http://www.simpy.com/ - Tag -
This is precisely what I want to do. Yes, I can add JNDI entries to various
Jetty XML files, but this is good only if you have a fixed set of indices known
ahead of time (before starting the servlet container). I want the ability to
add and remove indices on the fly, while the servlet
I'll have a look at this later today or tomorrow (don't have source code +
project handy at the moment), but somebody else might get to it before me.
Otis
- Original Message
From: Tom Hill [EMAIL PROTECTED]
To: solr-dev@lucene.apache.org
Sent: Friday, July 27, 2007 12:43:09 AM
Subject:
I think (re)using solrj is a good idea. As a client, I'd rather have one API
to use for both distributed and non-distributed calls to Solr.
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
From: Yonik Seeley [EMAIL PROTECTED]
To:
I think this is going to be in 1.3. But Ryan friends will know for sure. :)
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
From: Shalin Shekhar Mangar [EMAIL PROTECTED]
To: solr-dev@lucene.apache.org
Sent: Thursday, December 13, 2007 4:42:53 AM
Huh? Should we clean this up?
Otis
- Original Message
From: Apache Wiki [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, December 20, 2007 5:52:30 AM
Subject: [Solr Wiki] Update of Prashant Chauhan by Prashant Chauhan
Dear Wiki user,
You have subscribed to a wiki page or wiki
???
Steve
On 12/20/2007 at 10:53 AM, Otis Gospodnetic wrote:
Huh? Should we clean this up?
Otis
- Original Message
From: Apache Wiki [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, December 20, 2007 5:52:30 AM
Subject: [Solr Wiki] Update of Prashant Chauhan by Prashant Chauhan
Yonik,
While blazing through my Hadoop folder with the Delete key floored, I came
across this:
http://wiki.apache.org/lucene-hadoop/DistributedLucene
It will look very familiar to you, but it looks like this just added to Hadoop
wiki. I'm wondering if this overlaps with SOLR-303?
Otis
A comment from the sidelines:
- I haven't taken a close look at the new log format yet
- I think *appending* the core name might be better than inserting it at the
beginning of the message, just in case people are analyzing logs and not
counting on a new field suddenly showing up in their Solr
Hi,
Summary: How about having more than 1 (Solr)IndexSearcher per index in order to
avoid Lucene's synchronization bottlenecks?
There are those few synchronized points in Lucene - the stuff around IndexInput
and such. One in a while I hear from people who've done extensive benchmarking
or
Hi,
I was helping somebody who's getting stuck with temporary indices (index.tmp*)
due to some hardware/network error. I saw the following in snapinstaller:
cp -lr ${name}/ ${data_dir}/index.tmp$$
/bin/rm -rf ${data_dir}/index
mv -f ${data_dir}/index.tmp$$ ${data_dir}/index
Would it be
Haven't used SCRH in a while, but what you are describing sounds right
(thinking about how Google does it) - each word should be checked separately
and we shouldn't assume splitting on whitespace. I'm trying to think if there
are cases where you'd want to look at the surrounding terms instead
be nice to do
term n-gramming in order to check the terms in context.
Since Otis brought up Google, here is an example of putting the term
into context.
http://www.google.com/search?q=choudhury
http://www.google.com/search?q=abdur+choudhury
-Sean
Otis Gospodnetic wrote:
Haven't used
Lots of Lucene indexing improvements in Lucene 2.3.*
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
From: Noble Paul നോബിള് नोब्ळ् [EMAIL PROTECTED]
To: solr-dev@lucene.apache.org
Sent: Sunday, March 2, 2008 5:23:28 AM
Subject: Solr 1.2
: Sunday, March 2, 2008 11:06:42 PM
Subject: Re: Solr 1.2 performance
Can I use lucene 2.3 with Solr1.2? Is it tested?
Do I need to make any configuration changes?
--Noble
On Mon, Mar 3, 2008 at 2:37 AM, Otis Gospodnetic
wrote:
Lots of Lucene indexing improvements in Lucene 2.3.*
Otis
Hi Aerik,
I don't think there are specs (if there are, they could be on the Wiki), but
here are some pointers:
[EMAIL PROTECTED] src]$ ff \*JSON\*java
./test/org/apache/solr/request/JSONWriterTest.java
./java/org/apache/solr/request/JSONResponseWriter.java
[EMAIL PROTECTED] src]$ ff
I think that sounds correct. Why not also include solrconfig.xml? Also, why
bother with checking timestamps of those .xml files - they are small enough
that it's not worth complicating scripts to save a few KB of xfer only when
those files change. But maybe you want that to detect their
Hi Contributor ;)
I think this is a good suggestion. I think Lucene's contrib/ is working OK, so
I think it's safe to follow that approach. If we observe that something in
contrib/ is *so* frequently used or very core in some way, we can svn mv it and
carry on.
Otis
--
Sematext --
I *think* Yonik or Hoss have to manually give you JIRA privileges...
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Forwarded Message
From: Koji Sekiguchi (JIRA) [EMAIL PROTECTED]
Koji Sekiguchi commented on SOLR-319:
-
Hi,
I was hunting for a way to set a JIRA issue status to In Progress (see
http://confluence.atlassian.com/display/JIRA/Issue+status+and+workflow ), but
couldn't find it. It looks like that comes with Workflow Actions and Solr's
has only Resolve Issue and Close Issue. I see this on JIRA's
Hi,
Half-baked things getting into trunk probably won't happen. Lots of people use
Solr nightlies (cause they are often stable enough). If we were a bunch paid
to work on Solr, then we'd be more organized/structured and have more regular
release cycles. Solr is also not likely to have a
I'll take the contrib/ issue if nobody else does. I would want to see that one
in 1.3, so we can get DataImportHandler in.
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
From: Shalin Shekhar Mangar [EMAIL PROTECTED]
To:
I've been meaning to email Jason/solr-dev and suggest the same thing. Jason's
JIRA issues and patches seem to make some radical changes in the heart of Solr
and without any discussion (and often very brief JIRA descriptions) it's hard
(for me) to follow and feel confident about applying those
Hi,
Am I the only one who is seeing consistent failures of
org.apache.solr.client.solrj.response.QueryResponseTest when running ant test?
testcase classname=junit.framework.TestSuite$1 name=warning
time=0.0060
failure message=No tests found in
Bingo. The way of the future, ha?
Thanks!
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
From: Chris Hostetter [EMAIL PROTECTED]
To: solr-dev@lucene.apache.org
Sent: Thursday, May 22, 2008 1:11:14 AM
Subject: Re: QueryResponseTest failure
I agree. Lots of what Jason is doing looks good, but like I pointed the other
day, needs a lot more explanation, at least for dense people like moi. My
guess is, if we want to be aggressive with 1.3, that none of Jason's stuff will
make it because the changes are too radical, unless somebody
Hi,
This is mainly for people who contribute patches to Solr:
http://wiki.apache.org/solr/HowToContribute#head-0b17c0b8ff6e1940affd2f420b59549845a0ec9a
This should help us bring a little more order in Solr JIRA and make it easier
to review patches and get them committed.
Thanks,
Otis
--
)
-
+
+32. SOLR-505: Give RequestHandlers the possiblity to suppress the
generation
+of HTTP caching headers. (Thomas Peuss via Otis Gospodnetic)
+
+33. SOLR-553: Handle highlighting of phrase terms better when
+hl.usePhraseHighligher=true URL param is used.
+(Bojan Smid
I think I'd prefer to have that single core instance and a slower first request
instead of doing extra initialization work and then letting extra instances
linger... seems cleaner.
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
From: Chris
I'm +1 on getting the basic stuff done and committed for 1.3.
If Grant is hot on getting the abstractions in for 1.3, he will do so, but I
think it's OK to get this done in 2 parts:
1) core working and committed for 1.3
2) abstractions working and committed after 1.3 if Grant doesn't finish them
Yeah, as an observer I sensed no bad intentions here.
Anyhow, 1.3 is not scheduled yet, my guess is we are still at least a few weeks
away from 1.3 (and if I had to bet I'd bet at 1.3 being released close to the
end of summer). Grant is very eager about this and will get it all in. Case
I'm pro 6.1.11. I've used it on several occasions now and haven't seen any
problems with it.
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
From: Norberto Meijome [EMAIL PROTECTED]
To: solr-dev@lucene.apache.org
Sent: Saturday, July 12, 2008
May the force be with you. +1
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
From: Grant Ingersoll [EMAIL PROTECTED]
To: solr-dev@lucene.apache.org
Sent: Tuesday, August 5, 2008 3:46:26 PM
Subject: [VOTE] Set Solr 1.3 freeze and release
I wasn't aware of it either :)
I like the idea of keeping it separate, mostly because I fear the core
CHANGES.txt growing super big and thus harder for people to use, especially as
contrib/ starts growing.
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original
I wouldn't worry about moving of already recorded changes (i.e. cleanup). I'd
just do the right thing from now on.
Getting 1.3 out next week sounds much more interesting to me. :)
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
From: Shalin
Brian, you may want to open a new issue for this if this still doesn't exist.
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
From: Brian Whitman (JIRA) [EMAIL PROTECTED]
To: solr-dev@lucene.apache.org
Sent: Sunday, June 22, 2008 10:39:45 AM
Hi
Look mom, only 3 issues to go!
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=12310230fixfor=12312486
Out of those, 1 is trivial (lucene jar update), 1 looks committed (the maven
one), and only SOLR-646 is
+1. Maybe just wait a few more days for LUCENE-1333 - it looks like Mike will
commit in a few days.
Otis
- Original Message
From: Yonik Seeley [EMAIL PROTECTED]
To: solr-dev@lucene.apache.org
Sent: Monday, August 18, 2008 2:33:29 PM
Subject: upgrade lucene
So it looks like
I very much agree!
I even feel that SOLR-646 could go in as-is (basing this on Ryan's useful
summary of that issue's latest status) today.
Grant, any chance you can do a release this Friday or next Monday?
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original
That's a good and valid point that applies most of the time.
So is SOLR-646 ready to go now? Personally, I'm for getting 1.3 released now
and polishing between 1.3 and 1.3.1.
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
From: Noble Paul
+1 for Lucene upgrade
+1 for a release (I *think* none of the recent SOLR-7** issues have to go in
1.3)
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
From: Erik Hatcher [EMAIL PROTECTED]
To: solr-dev@lucene.apache.org
Sent: Monday, August
Grant, if you have time to make the RC today, we could run it until next
weekend and have the 1.3 released on Monday.
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
From: Shalin Shekhar Mangar [EMAIL PROTECTED]
To: solr-dev@lucene.apache.org
Just came across http://wiki.apache.org/solr/IndexPartitioning . Does anyone
think we still need this idea (vs. MultiCore)?
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
Glenn,
This sounds very much like shingles of variable length (1 to length(terms in
query)). Make sure you turn them into phrase queries and combine them with ORs
and things should work then.
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
Hi,
CoreContainer is new, so maybe I'm just not yet intimately familiar with it,
but I wonder if newcomers to Solr will be confused by the name CoreContainer
which sounds rather singular, when in fact it seems to hold references to all
SolrCores. Maybe native English speakers will
Grant, here is what it's supposed to be: Gospodnetić
If Forrest and friends don't like that diacritic, I suppose I can live with
Gospodnetic -- damn i18n! ;)
This is what I see locally:
$ ffxg Gospod
./src/site/src/documentation/content/xdocs/who.xml: liOtis
Gospodneti#263;/li
$ find .
it :(
Otis
- Original Message
From: Otis Gospodnetic [EMAIL PROTECTED]
To: solr-dev@lucene.apache.org
Sent: Friday, August 29, 2008 3:13:39 PM
Subject: Re: prototype Solr 1.3 RC 1
Grant, here is what it's supposed to be: Gospodnetić
If Forrest and friends don't like
Thank you Steve! See, I knew you'd nail it. I don't want to complicate lives
of others just because of one little diacritic.
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
From: Steven A Rowe [EMAIL PROTECTED]
To: solr-dev@lucene.apache.org
I'm not a huge facet user, so I can't tell with certainty how good your
suggestion is, but from your description the change sounds good.
It also reminds me what I did here: http://www.simpy.com/user/otis/links
If you look above the tags on the right side of the page you will see: View:
alpha ·
I agree with Mike. The simpler you make it the higher the chances of the plan
being followed. I had to re-read the part about un-released versions.
Moreover, rigid rules work great when people doing the work can really spend
quality time on the project. This means that people working on
release should represent a priority
to the issue from us. The core of my suggestion is continuous release
planning to ensure releasing early and releasing often. It is also an
incentive to scope issues appropriately.
On Tue, Sep 23, 2008 at 12:08 AM, Otis Gospodnetic
[EMAIL PROTECTED] wrote
Hi,
When people add new issues to JIRA they most often don't set the Fix Version
field. Would it not be better to have a default value for that field, so that
new entries don't get forgotten when we filter by Fix Version looking for
issues to fix for the next release? If every issue had Fix
+1. Seems a bit easier/faster than JIRA+Patch+Apply.
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
From: Grant Ingersoll [EMAIL PROTECTED]
To: solr-dev@lucene.apache.org
Sent: Friday, October 3, 2008 6:02:21 AM
Subject: Re: solr 2.0
This is related to something I must have only day dreamed (dreamt?) about, but
not actually mentioned on solr-dev.
My feeling is we are moving Solr in a direction of a more general web service
that can host various NLP and ML components, and no longer only do IR/Lucene.
We see that with a few
Hi,
I can't believe this idea received no replies! I wonder how many companies are
already doing what Mark described here. ;)
In any case, I think this is HUGE. If you believe any of the enterprise search
pundits, these connectors are essential to get Solr to be recognized as
enterprise
Quick thought. I saw Stefan's Katta presentation last night. Katta seems nice
and simple. If I understood correctly, juicy stuff that is interesting to Solr
is:
- Katta has a notion of a Primary Master and N Secondary Slaves (no SPOF there)
- Search Nodes serve index shards copied locally
with the developments in other projects .
On Tue, Nov 11, 2008 at 11:45 PM, Otis Gospodnetic
[EMAIL PROTECTED] wrote:
Quick thought. I saw Stefan's Katta presentation last night. Katta seems
nice and simple. If I understood correctly, juicy stuff that is interesting
to Solr is:
- Katta has
https://issues.apache.org/jira/secure/attachment/12394376/solr_sp.png
https://issues.apache.org/jira/secure/attachment/12394218/solr-solid.png
https://issues.apache.org/jira/secure/attachment/12394475/solr2_maho-vote.png
is this one ok?
For what it's worth, I'm pro keeping contrib things in their own jars. It's
easy to figure out what you need to include when/if you need it, but it pains
me to carry around jars with code that I have absolutely no need for.
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
Quick clarifications:
- Droids: http://incubator.apache.org/droids/index.html
- DIH: http://wiki.apache.org/solr/DataImportHandler
- Solr + Tika: http://wiki.apache.org/solr/ExtractingRequestHandler
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
Doesn't that mean that you are doing something that causes searchers to warm up
(e.g. running snap* scripts or your new replication equivalent) and doing that
so frequently that when you do this for the third time the first two searchers
are still warming up?
Otis
--
Sematext --
I'd simply address that first. I feel that's the first question people will
ask (themselves). But, sorry for the interruption. :)
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
From: Noble Paul നോബിള് नोब्ळ् noble.p...@gmail.com
To:
Isn't Lucene's ParallelReader meant to address such use cases? Don't ask me
for details, the actual use of PR always seemed a bit fuzzy to me because of
its requirement to keep docIDs in sync.
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
+1
I think we could try just comment out the kitchen sick portions and avoid
maintaining 2 config files.
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
From: Shalin Shekhar Mangar shalinman...@gmail.com
To: solr-dev@lucene.apache.org;
Want to open a JIRA issue (Enhancement?)
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
From: KaktuChakarabati jimmoe...@gmail.com
To: solr-dev@lucene.apache.org
Sent: Monday, March 23, 2009 3:12:16 PM
Subject: JCache API and EHCache
Hi,
At which point would you say the number of cached bitsets should be considered
excessive? Simply a function of bitset size (index size) and memory/JVM heap?
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
From: Jason Rutherglen
Could you please re-send your message to solr-user instead?
Thanks,
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
From: sunnyfr johanna...@gmail.com
To: solr-dev@lucene.apache.org
Sent: Thursday, March 26, 2009 9:29:40 AM
Subject:
I like the multilingualness is general... but in this case I think Grant is
correct about non-primary language docs getting outdated quickly. It's hard to
keep even just English docs up to date! And stale, incorrect docs are worse
than no docs.
Otis
--
Sematext -- http://sematext.com/ --
I wonder if it would be useful to commit Lucene's CHANGES.txt into Solr along
with Solr jars. It would then be very easy to tell what changed in Lucene
since the version Solr has and the current version of Lucene (or some newer
released version, if we were able to be behind).
Otis
--
Clearly I meant ...along with *Lucene* jars :)
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
From: Otis Gospodnetic otis_gospodne...@yahoo.com
To: solr-dev@lucene.apache.org
Sent: Wednesday, May 27, 2009 11:59:18 PM
Subject: Re: update
1 - 100 of 440 matches
Mail list logo
