field (via copyField, perhaps).
> > >
> > > Brad
> > >
> > >
> > >
> > >
> > > -Original Message-
> > > From: Salman Akram [mailto:salman.ak...@northbaysolutions.net]
> > > Sent: January-17-11 5:47 AM
> > &g
s you
> > happen to already have such a field (via copyField, perhaps).
> >
> > Brad
> >
> >
> >
> >
> > -Original Message-
> > From: Salman Akram [mailto:salman.ak...@northbaysolutions.net]
> > Sent: January-17-11 5:47 AM
> > To: s
ll probably have to re-index your data, unless you
> happen to already have such a field (via copyField, perhaps).
>
> Brad
>
>
>
>
> -Original Message-
> From: Salman Akram [mailto:salman.ak...@northbaysolutions.net]
> Sent: January-17-11 5:47 AM
> To: solr-
lman Akram [mailto:salman.ak...@northbaysolutions.net]
Sent: January-17-11 5:47 AM
To: solr-user@lucene.apache.org
Subject: Re: sort problem
Yes.
On Mon, Jan 17, 2011 at 2:44 PM, Philippe VINCENT-ROYOL <
vincent.ro...@gmail.com> wrote:
> Le 17/01/11 10:32, Grijesh a écrit :
>
>
Yes.
On Mon, Jan 17, 2011 at 2:44 PM, Philippe VINCENT-ROYOL <
vincent.ro...@gmail.com> wrote:
> Le 17/01/11 10:32, Grijesh a écrit :
>
> Use Lowercase filter to lowering your data at both index time and search
>> time
>> it will make case insensitive
>>
>> -
>> Thanx:
>> Grijesh
>>
> Thanks
Le 17/01/11 10:32, Grijesh a écrit :
Use Lowercase filter to lowering your data at both index time and search time
it will make case insensitive
-
Thanx:
Grijesh
Thanks,
so tell me if i m wrong... i need to modify my schema.xml to add
lowercase filter and reindex my content?
Use Lowercase filter to lowering your data at both index time and search time
it will make case insensitive
-
Thanx:
Grijesh
--
View this message in context:
http://lucene.472066.n3.nabble.com/sort-problem-tp2271207p2271231.html
Sent from the Solr - User mailing list archive at Nabble.com.
On 9/3/07, Marcus Stratmann <[EMAIL PROTECTED]> wrote:
> > If you could live with a cap of 2B on message id, switching to type
> > "int" would decrease the memory usage to 4 bytes per doc (presumably
> > you don't need range queries?)
>
> I haven't found exact definitions of the fieldTypes anywhere
If you could live with a cap of 2B on message id, switching to type
"int" would decrease the memory usage to 4 bytes per doc (presumably
you don't need range queries?)
I haven't found exact definitions of the fieldTypes anywhere. Does
"integer" span the common range from -2^31 to 2^31-1?
And t
I'll try switching to int. Thanks.
Yonik Seeley <[EMAIL PROTECTED]> wrote: On 9/2/07, michael ravits wrote:
> this is the field definition:
>
>
> holds message id's, values range from 0 to 127132531
> can I disable this cache?
No, sorting wouldn't work without it.
The cache structure certai
On 9/2/07, michael ravits <[EMAIL PROTECTED]> wrote:
> this is the field definition:
> required="true" />
>
> holds message id's, values range from 0 to 127132531
> can I disable this cache?
No, sorting wouldn't work without it.
The cache structure certainly isn't optimal for this (every doc
hello mike,
this is the field definition:
holds message id's, values range from 0 to 127132531
can I disable this cache?
Mike Klaas <[EMAIL PROTECTED]> wrote: On 28-Aug-07, at 6:19 AM, michael ravits
wrote:
> hello solrs,
>
> i have an index with 30M records, weights ~50GB. latest trunk
On 28-Aug-07, at 6:19 AM, michael ravits wrote:
hello solrs,
i have an index with 30M records, weights ~50GB. latest trunk
version. heap size 1024mb.
queries work fine until I specify a field to sort results by. even
if the result set consists of only 2 documents, the CPU jumps high
and
: I have read that the default sorting is by the "score desc".
: However when I ran the query, I get some erroneous results.
:
: This is the query I ran:
:
: solr include_in_directory_p:t AND active_p:t AND (in_shelves:(0777,1)^100
: OR in_groups:(02343^50 02345^30 abc xyz)); score desc
what vers
14 matches
Mail list logo
