hi,
we have been trying to get the leading wildcards to work.
we have been looking around the Solr website, the Lucene website, wiki's
and the mailing lists etc ...
but we found a lot of contradictory information.
so we have a few question :
- is the latest version of lucene capable of
I've investigated this recently, and it looks like the latest lucene dev
supposedly supports leading/trailing at the same time. However, I couldn't
get the latest dev solr to build with the latest dev lucene (as of two weeks
ago). A lucene mailing list seemed to indicate that lucene as of the
I can't seem to get things like facet.mincount to work.
We had same issue when we used Solr incubator version.
Now we are using trunk version of Solr and the issue was gone.
Where is this trunk version? I thought
apache-solr-1.1.0-incubating.zip was the latest release. Can anyone
provide a
On 4/19/07, Jennifer Seaman [EMAIL PROTECTED] wrote:
I can't seem to get things like facet.mincount to work.
We had same issue when we used Solr incubator version.
Now we are using trunk version of Solr and the issue was gone.
Where is this trunk version?
trunk is a reference to the source
On 4/19/07, Doss [EMAIL PROTECTED] wrote:
It seems the snapshooter takes the exact copy of the indexed data, that is all
the contents inside the index directory, how can we take the recently added
once?
...
cp -lr ${data_dir}/index ${temp}
mv ${temp} ${name} ...
I don't quite understand
On Apr 19, 2007, at 6:56 AM, Michael Kimsal wrote:
It's bugged us a little bit, because it's something that we need
(to be able to emulate the previous foo LIKE '%bar%' SQL behaviour
we're
replacing), but can't offer our users yet.
I have also run into this issue and have intended to fix
Agreed, but in our tests (100M index) it wasn't a performance hit, and much
better (as in it actually worked) than MSSQL ;)
On 4/19/07, Erik Hatcher [EMAIL PROTECTED] wrote:
On Apr 19, 2007, at 6:56 AM, Michael Kimsal wrote:
It's bugged us a little bit, because it's something that we need
On 4/19/07, Erik Hatcher [EMAIL PROTECTED] wrote:
parser.setAllowLeadingWildcards(true);
I have also run into this issue and have intended to fix up Solr to
allow configuring that switch on QueryParser.
Any reason that parser.setAllowLeadingWildcards(true) shouldn't be the default?
Does it
On Apr 19, 2007, at 9:32 AM, Jennifer Seaman wrote:
Can anyone provide a quick tutorial on how to setup facet browsing?
After a keyword search I just want to allow the user to narrow the
results by category, then by state, then by city and then by company.
Some sample code would be
On Apr 19, 2007, at 10:39 AM, Yonik Seeley wrote:
On 4/19/07, Erik Hatcher [EMAIL PROTECTED] wrote:
parser.setAllowLeadingWildcards(true);
I have also run into this issue and have intended to fix up Solr to
allow configuring that switch on QueryParser.
Any reason that
It still seems like it's only something that would be invoked by a user's
query.
If I queried for *foobar and leading wildcards were not on in the server,
I'd get back nothing, which isn't really correct. I'd think the application
should
tell the user that that syntax isn't supported.
Perhaps
On Apr 19, 2007, at 11:04 AM, Michael Kimsal wrote:
Perhaps I'm simplifying it a bit. It would certainly help out our
comfort
level
to have it either be on or configurable by default, rather than
having to
maintain a
'patched' version (yes, the patch is only one line, but it's the
I recommend you build your query with facet options in raw format and
make sure you're getting back the data you want. Then build it into
your app.
On 4/18/07, Jennifer Seaman [EMAIL PROTECTED] wrote:
Does anyone have any sample code (php, perl, etc) how to setup facet
browsing with paging? I
I'm in the middle of looking in to that. For *you* ;) it may seem like a
quick
thing to do. For me, who's not an expert at this stuff, it's a balance
between delving in
deeply enough to figure how to do it and hitting our deadlines.
It's actually on someone else's plate here, but he's backed
On Apr 19, 2007, at 11:37 AM, Michael Kimsal wrote:
It's not that I don't *want* to contribute, but hardly have enough
time to
get the basics
done some days.
You can rest assured that all of us here are in that same boat. :)
And you can also rest assured that the switch your asking for
Hi,
Does the acts_as_solr supports now fancier results such as highlight?
Although I see options to use facets but have not yet explored with the
plugin.
TIA
-amit
Erik Hatcher wrote:
On Aug 28, 2006, at 10:25 PM, Erik Hatcher wrote:
I'd like to commit this to the Solr repository. Any
Why not just store an additional object_type field which
differentiates between the actual type of data you are looking for?
So if you're looking for some shoes:
(size:8 AND color:'blue') AND object_type:'shoe'
Or if you're searching on brands
(genre:'skater' AND brand_desc:'skater boy') AND
You can not have more than one Solr core per application (to be precise, per
class-loader since there are a few statics).
One way is thus to have 2 webapps - when if indexes do not have the same
lifetime/radically different schema/etc.
However, the common wisdom is that you usually dont really
On 4/18/07, Yonik Seeley [EMAIL PROTECTED] wrote:
On 4/18/07, Koji Sekiguchi [EMAIL PROTECTED] wrote:
I can't seem to get things like facet.mincount to work.
We had same issue when we used Solr incubator version.
Now we are using trunk version of Solr and the issue was gone.
Hmmm, good
If you're doing this in Ruby, there is an acts_as_solr plugin for
Rails which takes exactly this approach to store all different kinds
of Model objects in the same index...I just took the idea from
there...
/Cody
On 4/19/07, Matthew Runo [EMAIL PROTECTED] wrote:
Ah hah! This appears to be what
There is still only one solr.home instance used to load the various classes
which is used as the one 'root'.
From there, you can have multiple solrconfig*.xml schema*.xml (even
absolute pathes); calling new SolrCore(name_of_core, path_to_solrconfig,
path_to_schema) creates a named core that you
I'll actually be doing this in Perl..
any ideas on perl? heh
++
| Matthew Runo
| Zappos Development
| [EMAIL PROTECTED]
| 702-943-7833
++
On Apr 19, 2007, at 11:59 AM, Cody
I have a bunch of fields that I am trying to filter on.
When I try to filter the data across the multiple fields, the result seems
to even retrieve fields where the data is not present.
For instance if the filter query contains this -
primary_state:New Delhi OR primary_country:New Delhi OR
Matthew,
All that is meant by object_types is an additional stored/indexed
field in the Solr schema that gets added to every document providing
context of which type it is (shoes or brands). Then you can limit
searches to a particular area by just filtering on type:shoes, for
example.
Is there a way to only retrieve those records that contain both the
words New and Delhi.
I'm just starting with this, put I found you need to do;
primary_state:New Delhi
I never used the OR yet!
On 4/19/07, Cody Caughlan [EMAIL PROTECTED] wrote:
This is more of a Lucene question than a Solr one, but... is it
possible to query a Solr(Lucene) index while it is in the middle of
performing a commit/optimize?
Yep, no problems. You can query concurrently with adds, deletes,
commits, and
Ok, cool. At the worse case, are you just not going to get any hits,
even though you know the data is in there, but it just hasnt been
indexed yet?
How does that work?
/cody
On 4/19/07, Yonik Seeley [EMAIL PROTECTED] wrote:
On 4/19/07, Cody Caughlan [EMAIL PROTECTED] wrote:
This is more of a
Ah. That makes sense then. I wasn't sure if that was the best way to
go about things or not. I didn't want to end up with a bunch of
fields that were not being used all the time if it would cause a
degradation in search quality.
++
I don't really know alot about Ruby, but as i understand it there are more
then a few versions of something called acts_as_solr floating arround
... the first written by Erik as a proof of concept, and then pickedu pand
polished a bit by someone else (whose name escapes me)
all of the serious
: I want to do a simple query to the solr index. something like
: q=stateid:1 countryid:1
:
: but i'm really only concerned with getting the record above and below a
: certain (dynamic) recordid in the search results.
you have to define what above and below means in your context ... do you
mean
: Is there a good spot to track request rate in Solr? Has anyone
: built a monitor?
I would think it would make more sense to track this in your application
server then to add it to Solr itself.
-Hoss
: Any reason that parser.setAllowLeadingWildcards(true) shouldn't be
: the default?
i'm of two minds on this, both of which vote don't do it
from a predictibility standpoint, i think we should keep the default
beahvior the same as the base QueryParsers default behavior as much as
possible
: with special characters from tokenizing, sat for example A+, A1+ etc.
: because when i searched for group A i am getting results with A+
: aswell as A1+ and so on, is there any special way to index these type of
: words?
all fo the tokenization is controlled via the analyzers you configure in
On 4/19/07, Yonik Seeley [EMAIL PROTECTED] wrote:
from a stability standpoint, i would suggest that people should have to go
out of their way to get this behavior, since it does open up the
possiblity of a query OOMing Solr extremely easily.
ConstantScorePrefixQuery is used... there
: So if you're looking for some shoes:
: (size:8 AND color:'blue') AND object_type:'shoe'
: Or if you're searching on brands
: (genre:'skater' AND brand_desc:'skater boy') AND object_type:'brand'
a slight improvement on this: put your object_type restriction in a
filter query
: For things that return results, yes. I think that taking away
: features isn't a good thing, but adding them can be (basically,
: backward compatibility).
i don't know that this is really dding a feature ... it's changing syntax.
foo:*bar has meaning by default in the query parser ... it's
: ConstantScorePrefixQuery is used... there shouldn't be an issue with
: memory, just time.
:
: Oops, except we aren't always talking about a prefix query.
: I know at least some expanding queries automatically limit to the max
: number of boolean clauses. Not sure if all of them do though.
: not find it, if there were other words in between (e.g. New Capital Delhi).
then you should use field:New Delhi~3 or (+field:New +field:Delhi) what
you have now is going to match any docs that have New in any of the
fields you care about or Delhi in whatever you default search field is.
Thanks Chris. We are using dismax already :)
Chris Hostetter wrote:
: not find it, if there were other words in between (e.g. New Capital
Delhi).
then you should use field:New Delhi~3 or (+field:New +field:Delhi) what
you have now is going to match any docs that have New in any of the
On 4/19/07, Chris Hostetter [EMAIL PROTECTED] wrote:
: For things that return results, yes. I think that taking away
: features isn't a good thing, but adding them can be (basically,
: backward compatibility).
i don't know that this is really dding a feature ... it's changing syntax.
foo:*bar
As this question comes up so often, i put a new page on the wiki:
http://wiki.apache.org/solr/MultipleIndexes
We should fill in more details and link it to the front page.
Chris Hostetter wrote:
: So if you're looking for some shoes:
: (size:8 AND color:'blue') AND object_type:'shoe'
: Or
: i don't know that this is really dding a feature ... it's changing syntax.
: foo:*bar has meaning by default in the query parser ... it's meaning may
: typically result in a query that doesn't match anything,
:
: I think it's adding syntax, not changing it.
: Right now, you get an exception
Hello,
in my logs I get from time to time this message:
INFO: PERFORMANCE WARNING: Overlapping onDeckSearchers=2
What does this mean? What can I do to avoid this?
Cheers,
Michael
I'm sorry to say I am *way* behind on my patch reading (and moving into my
new place this weekend where i have no net access isn't going to help) so
i can't comment on the technique (or even style) of this patch ... but if
you could do peopel a favor and open a Jira issue and post it there for
On Apr 19, 2007, at 7:47 PM, Michael Thessel wrote:
in my logs I get from time to time this message:
INFO: PERFORMANCE WARNING: Overlapping onDeckSearchers=2
What does this mean? What can I do to avoid this?
I think you have issued multiple commits (or optimizes) that hadn't
fully
Sorry, I missed the original mail. Hoss has got it right.
Personally I'd love to see acts_as_solr definitively come into the
solr-ruby fold.
Regarding your questions:
: 1. What are other alternatives are available for ruby integration
with solr
: other than acts-as_solr plugin.
i read it from http://wiki.apache.org/solr/IndexInfoRequestHandler
--
regards
jl
James liu wrote:
i read it from http://wiki.apache.org/solr/IndexInfoRequestHandler
The IndexInfoRequestHandler was added since the solr 1.1. You will need
to compile the source from:
http://svn.apache.org/repos/asf/lucene/solr/trunk/
to get the IndexInfo handler.
I know it should be configed in solrconfig.xml.
and i think it may be with newest version.
But i find no, so i just think is it problem when i download.
2007/4/20, Erik Hatcher [EMAIL PROTECTED]:
On Apr 19, 2007, at 9:42 PM, James liu wrote:
i read it from
When mutiple facet queries are specified, are they booleaned as OR or
AND?
-Yao
Never mind. I should have read the example
(http://wiki.apache.org/solr/SimpleFacetParameters#head-1da3ab3995bc4abc
dce8e0f04be7355ba19e9b2c) first.
From: Ge, Yao (Y.)
Sent: Thursday, April 19, 2007 10:41 PM
To: 'solr-user@lucene.apache.org'
Subject: Facet.query
51 matches
Mail list logo
