ugins)" heading under it. Then that link shows 14 patches.
So, if you have a moment, could you list the patches that I need to
get to test this? If not, I would be more than happy to read any
documentation how to understand the patching process.
On Feb 4, 2008 11:52 AM, Briggs <[EM
Is it possible to limit the number of duplicate field values are
returned in a search result?
To give a use case,
I have a set of products. Each product belongs to a single vendor.
When I query, I would like only n-number of results per vendor
returned.
Thanks!
--
"Conscious decisions by con
Cool, thanks!
On Feb 4, 2008 11:36 AM, Ryan McKinley <[EMAIL PROTECTED]> wrote:
> perhaps:
> https://issues.apache.org/jira/browse/SOLR-236
>
>
>
> Briggs wrote:
> > Is it possible to limit the number of duplicate field values are
> > returned in a searc
Searcher is the main search abstraction in Lucene. It defines the
methods used for querying an underlying index(es).
See:
http://lucene.apache.org/java/2_3_0/api/org/apache/lucene/search/Searcher.html
On Feb 12, 2008 10:33 PM, Mochamad bahri nurhabbibi <[EMAIL PROTECTED]> wrote:
> hello all..
>
multivalued field. The weird thing is that data is being
indexed for one row, meaning first raw_tag gets populated.
Anyone have any ideas?
Thanks,
Briggs
This is the relevant part of the schema:
And the relevant part of data-import.xml:
') as raw_tag, site.*
from site
left outer join
(freetags inner join freetagged_objects)
on (freetags.id = freetagged_objects.tag_id
and site.siteId = freetagged_objects.object_id)
group by site.siteId
Am I doing something wrong?
Thanks,
Briggs Thompson
On Thu, Dec 1, 2011 at
ransformer"
in the entity declaration.
Anyhow, thanks for the quick response!
Briggs
On Thu, Dec 1, 2011 at 12:57 PM, Rahul Warawdekar <
rahul.warawde...@gmail.com> wrote:
> Hi Briggs,
>
> By saying "multivalued fields are not getting indexed prperly", do you mean
&
background about the data: it is extremely variable. Some documents
contain only 2 or 3 sentences, and some are 20 page extracted PDFs. There
would probably only be about 100-150 unique fields.
Any input is greatly appreciated!
Thanks,
Briggs Thompson
ghlighting essentially returns the hit count if you
supply unlimited amount of snippets, but I imagine there must be a more
elegant solution.
Thanks in advance,
Briggs
Yes indeed, that is what I was missing. Thanks Ahmet!
On Tue, Jul 5, 2011 at 12:48 PM, Ahmet Arslan wrote:
>
> > Is there a good way to get the hit count of a search?
> >
> > Example query:
> > textField:solr AND documentId:1000
> >
> > Say document with Id = 1000 has "solr" 13 times in the
> >
the field is defined assuming the query is
correct.
Briggs Thompson
On Thu, Jul 7, 2011 at 12:22 PM, Christopher Cato <
christopher.c...@minimedia.se> wrote:
> Hi, I'm running Solr 3.2 with edismax under Tomcat 6 via Drupal.
>
> I'm having some problems writing a query t
the desired search logic is, but it probably isn't. Check
out the documentation on each of the tokenizers and filter factories in your
"text" field type and see what you need and what you don't to satisfy your
use cases.
Hope that helps,
Briggs Thompson
On Fri, Jul 8, 2011 at 9:
individual
document types - all in the same core.
Briggs Thompson
On Mon, Jul 18, 2011 at 2:22 AM, pravesh wrote:
> >a single core is an index with same schema , is this wat core really is ?
>
> YES. A single core is a independent index with its own unique schema. You
> go with
Thanks Erik. If anyone else has any ideas about the NoSuchFieldError issue
please let me know. Thanks!
-Briggs
On Mon, Jul 2, 2012 at 6:27 PM, Erik Hatcher wrote:
> Interestingly, I just logged the issue of it not showing the right error
> in the UI here: <https://issues.apache.org/ji
Also, I forgot to include this before, but there is a client side error
which is a failed 404 request to the below URL.
http://localhost:8983/solr/null/admin/system?wt=json
On Tue, Jul 3, 2012 at 8:45 AM, Briggs Thompson wrote:
> Thanks Erik. If anyone else has any ideas about
;
> i use an older solr-trunk version from february/march, it works. with
> newer versions from trunk i get the same error: "This interface
> requires that you activate the admin request handlers..."
>
> regards
> vadim
>
>
>
> 2012/7/3 Briggs Thompson :
p=/solr path=/update
params={stream.body=*:*}
{deleteByQuery=*:*} 0 0
But the corpus of documents in the core do not change.
My solrconfig is pretty barebones at this point, but I attached it in case
anyone sees something strange. Anyone have any idea why documents aren't
getting deleted?
Yury,
Thank you so much! That was it. Man, I spent a good long while trouble
shooting this. Probably would have spent quite a bit more time. I
appreciate your help!!
-Briggs
On Wed, Jul 18, 2012 at 9:35 PM, Yury Kats wrote:
> On 7/18/2012 7:11 PM, Briggs Thompson wrote:
> > I have
all Ids sent, although all
but one remain in the index.
I confirmed that the default update request handler deletes the list
properly, so this appears to be a problem with
the BinaryUpdateRequestHandler.
Not an issue for me, just spreading the word.
Thanks,
Briggs
On Thu, Jul 19, 2012 at 9:00 AM
Thanks Mark!
On Thu, Jul 19, 2012 at 4:07 PM, Mark Miller wrote:
> https://issues.apache.org/jira/browse/SOLR-3649
>
> On Thu, Jul 19, 2012 at 3:34 PM, Briggs Thompson <
> w.briggs.thomp...@gmail.com> wrote:
>
> > This is unrelated for the most part, but the javab
ectly replicating the data,
and it is searchable in the UI on the slave (but not master). I don't
understand how/why the data is visible on the slave and not visible on the
master. Does anyone have any thoughts on this or seen it before?
Thanks in advance!
Briggs
That is the problem. I wasn't aware of that new feature in 4.0. Thanks for
the quick response Tomás.
-Briggs
On Wed, Aug 1, 2012 at 3:08 PM, Tomás Fernández Löbbe wrote:
> Could your autocommit in the master be using "openSearcher=false"? If you
> go to the Master admin
when this
problem occurs, though.
This exception is causing the entire application to hang - which is
surprising considering all SolrJ logic is wrapped with try/catches. Has
anyone found out more information regarding the possible keep alive bug?
Any insight is much appreciated.
Thanks,
Briggs
Also note there were no exceptions in the actual Solr log, only on the
SolrJ side.
Thanks,
Briggs
On Mon, Oct 8, 2012 at 10:45 AM, Briggs Thompson <
w.briggs.thomp...@gmail.com> wrote:
> I have also just ran into this a few times over the weekend in a newly
> deployed system. We
I was looking for something in the solrconfig and
online but didn't find anything. I didn't look for very long so will check
it out again.
Some very good suggestions here. I appreciate everyones feedback. I will
follow up after some experimentation.
Thanks,
Briggs Thompson
On Tue,
There are other updates that happen on the server that do not fail, so the
answer to your question is yes.
On Wed, Oct 10, 2012 at 8:12 AM, Sami Siren wrote:
> On Wed, Oct 10, 2012 at 12:02 AM, Briggs Thompson
> wrote:
> > *Sami*
> > The client IS
> > instantiated onl
this correct?
On Wed, Oct 10, 2012 at 9:43 AM, Sami Siren wrote:
> On Wed, Oct 10, 2012 at 5:36 PM, Briggs Thompson
> wrote:
> > There are other updates that happen on the server that do not fail, so
> the
> > answer to your question is yes.
>
> The other updates are
t; On 10/9/2012 3:02 PM, Briggs Thompson wrote:
>
>> *Otis* - jstack is a great suggestion, thanks! The problem didn't happen
>>
>> this morning but next time it does I will certainly get the dump to see
>> exactly where the app is swimming around. I haven't used
&g
28 matches
Mail list logo