I understand the bottom line that soft commits are about visibility, hard
commits are about durability. I am just trying to gain better understanding
what happens under the hood...
2 more related questions you made me think of:
1. Does the NRTCachingDirectoryFactory relevant for both types of commi
Sorry, didn't get you exactly.
I need to warm up my queries after the newSearcher & firstSearcher are
initialized. I am trying to warm up the filter caches for a category field
but I have almost 1000 categories(& changing with time), which make it
impossible to list them in solrConfig.xml. Is ther
If you are asking to read from a file for warm up and if there is not a
capability for what you want I can open a Jira issue and send a patch.
2013/10/7 user 01
> what's the way to warm up filter queries for a category field with 1000
> possible values. Would I need to write 1000 lines manually
what's the way to warm up filter queries for a category field with 1000
possible values. Would I need to write 1000 lines manually in the
solrconig.xml or what is the format?
Upayavira thanks for replying.
When we run the quoted query in edismax, we get correct results. The only
problem is that the quoted queries are very slow.
Can you please point me to a link which talks about the quoted queries in
the edismax parser?
--
View this message in context:
http://l
Thanks
On Fri, Oct 4, 2013 at 5:56 PM, Jack Krupansky wrote:
> It all depends. I mean, if you have 20 million URLs averaging 40
> characters each, that's 80 MB, not a big deal at all, but if you have 20
> billion URLs that would take up 80 GB, which might be a big deal. But if
> you shard those
Hi David,
It's not exactly what I was looking for, but I will try it out to see if
it works for me. Thanks for your tips.
Jeroen
On 23-8-2013 8:02, David Smiley (@MITRE.org) wrote:
Hi Chris & Jeroen,
Tonight I posted some tips on Solr's wiki on this subject:
http://wiki.apache.org/solr/Spat
Seems the issue occurs when the shard has more than one replica.
I unload all replicas of the shard (less 1 to do the split) and the SPLITSHARD
finished as expected, the parent went to inactive and the children active.
If the parent has more than 1 replica, the process apparently is finish, the
Thanks Eric.
i hope i understood correctly, but my main concern is i have to tie specific
content indexed to a specific time range. and make that document come up in
search results only for that time. As i have mentioned in my previous
example we have multiple data-string structures which makes a
I have been using numeric ids through out my app so obviously that wont be
changed in my app. But I dont mind if Solr uses them as stringified.
On Sun, Oct 6, 2013 at 11:48 PM, Jack Krupansky
wrote:
> It all depends. Sorry I don't have a feature list, but there are places in
> Solr that assume
It all depends. Sorry I don't have a feature list, but there are places in
Solr that assume that the unique key field is a string, or at least
convertible to a string. So, as long as you don't use any of those features
of that unspecified list, you will be okay.
Is there any reason you require
@Jack Krupansky :
>you can put whatever application value (hopefully a string) you want into
your unique key field.
Is there any issue if I use an integer field type for id ?
On Sun, Oct 6, 2013 at 9:06 PM, Jack Krupansky wrote:
> Deep under the hood: Lucene is assigning a "Lucene document ID"
@Gora:
>One wants to index "just
>enough" data in the search engine. Plus, if one wants to do relevant
>searches in large text blobs, documents, etc., those should be in the
>search engine: Databases are bad at such searches.
Perhaps you took me wrong.. :) may be I couldn't make that clear.
I am
On Oct 6, 2013 9:50 PM, "Gora Mohanty"
> In particular, I would say that using just the ID in the search engine
makes little sense.
To elaborate further, you should be approaching the issue from the
perspective of the searches that your end users are likely to be doing. It
is unlikely that they a
On Oct 6, 2013 7:16 PM, "user 01" wrote:
>
> @Gora:
> you understood the schema correctly, but I can't believe it's strange but
i
> think it is actually the recommended way.. you index your data but don't
> store in a Search engine, you store your actual data in DB, which is the
> right place for
I'd like to have some suggestion on how to improve the indexing performance on
the following scenario
I'm uploading 1M docs to solr,
every docs has
id: sequential number
title: small string
date: date
body: 1kb of text
Here are my benchmarks (they are all single
Hi all
I've sent out this mail before, but I only subscribed to lucene-user but
not solr-user at that time. Sorry for repeating if any and your help will
be much of my appreciation.
I'm trying out the tutorial about solrcloud, and then I manage to write my
own plugin to import data from our set o
Deep under the hood: Lucene is assigning a "Lucene document ID" when Solr
adds a document. In fact, Lucene will assign a new Lucene document ID if you
ask Solr to update or replace a document. That said, Solr generally uses the
value from your unique key field as its "internal" ID, and you can p
Background: I need to find items matching keywords provided by user,
filtered by availability within certain radius from his location & filtered
by other user specific params.
So I think this may be very relevant for me because my filter queries may
be very unique all the time(since I am filtering
Hi
The approach I take is to store enough data in the SOLR index to render the
results page, and go to the database if the user want to view a document.
Cheers
François
On Oct 6, 2013, at 9:45 AM, user 01 wrote:
> @Gora:
> you understood the schema correctly, but I can't believe it's strang
Once again, why is it important to you? Curiosity or are you trying
to solve a problem?
Personally I've never had to worry about this kind of detail, so I've never
had cause to look. In essence, though, the terms are cached so they'll
occupy memory after you've queried on each of them so practical
@Gora:
you understood the schema correctly, but I can't believe it's strange but i
think it is actually the recommended way.. you index your data but don't
store in a Search engine, you store your actual data in DB, which is the
right place for it. Data in SE should be just used for indexing. Isn't
First, why is it important to you? General background or a specific
problem you're trying to address?
But to answer, no. The queryResultCache contains the top N
ids for the query. You control N by setting
in solrconfig.xml. It's often set to 2x the usual "rows" parameter
on the theory that people
On 6 October 2013 16:36, Ertio Lew wrote:
> I meant that solr should not be thinking that it has to retrieve any thing
> further (as in any stored document data) after once it gets the doc id, so
> that one further look up for doc data is prevented.
[...]
If I understood your setup correctly, the
Just use
and
myCustomAppId
and worry of nothing else
--
View this message in context:
http://lucene.472066.n3.nabble.com/Can-I-use-app-specific-document-id-as-the-document-id-that-Solr-uses-for-internal-purposes-tp4093715p4093727.html
Sent from the Solr - User mailing list archive at Nabble.
I meant that solr should not be thinking that it has to retrieve any thing
further (as in any stored document data) after once it gets the doc id, so
that one further look up for doc data is prevented.
On Sun, Oct 6, 2013 at 2:49 PM, Ertio Lew wrote:
> yeah I already configured it as a unique i
On 6 October 2013 14:49, Ertio Lew wrote:
> yeah I already configured it as a unique identifier,
> but how do I tell solr it should use that for its internal document id &
> not do unnecessary lookup/fetch for the document but instead just return
> the doc id as query response ?
[...]
I am not f
Does the queryResultCache, contain all the results returned by main query(q
param) or it contains results prepared after all filter queries ?
yeah I already configured it as a unique identifier,
but how do I tell solr it should use that for its internal document id &
not do unnecessary lookup/fetch for the document but instead just return
the doc id as query response ?
On Sun, Oct 6, 2013 at 2:18 PM, Gora Mohanty wrote:
> On 6 Octo
On 6 October 2013 14:16, Ertio Lew wrote:
> Could I just use my application specific document id as the document id
> that solr uses for internal purposes,
[...]
If this is a unique identifier, yes, you should be able to
do that.
Regards,
Gora
Could I just use my application specific document id as the document id
that solr uses for internal purposes, ie. indexing etc because I don't
store any other field other than id of the document(rest document data is
stored in DB). In my schema the only thing that I store is the document
id, this
sorry this question got posted twice. I wasn't aware.
On Sun, Oct 6, 2013 at 11:37 AM, Ertio Lew wrote:
> Are indexes for different fields maintained separately, I mean if I have
> two text fields both indexed separately within a schema, each of them would
> have its own set of indexes, so that
32 matches
Mail list logo
