ieve
that the Point fields are supposed to be fast. Not sure what the testing
environment was for that but that has not been our experience. I hope that
these Trie fields are going to stay in the product for Solr 9, I know they were
supposed to be removed in Solr 8 but there must have been a r
t been our experience. I hope that
these Trie fields are going to stay in the product for Solr 9, I know they were
supposed to be removed in Solr 8 but there must have been a reason they were
not.
Michael Cooper
Trie* fields will be supported through the 7x code line, so you have
quite a bit of time to plan your upgrade.
Best,
Erick
On Tue, Sep 26, 2017 at 6:04 AM, Shawn Heisey wrote:
> On 9/26/2017 2:23 AM, Bram Van Dam wrote:
>> We're preparing for an upgrade to 7.0, but I'm a bi
On 9/26/2017 2:23 AM, Bram Van Dam wrote:
> We're preparing for an upgrade to 7.0, but I'm a bit worried about the
> deprecation of Trie* fields. Is there any way to upgrade an existing
> index to use Point* fields without having to reindex all documents? Does
> the IndexUpgr
Hey folks,
We're preparing for an upgrade to 7.0, but I'm a bit worried about the
deprecation of Trie* fields. Is there any way to upgrade an existing
index to use Point* fields without having to reindex all documents? Does
the IndexUpgrader take care of this?
Thanks,
- Bram
#x27;t
> multivalued, so the term counts dont add up (how could I have more than
> 22404 terms if I only have 22404 documents). Why multiple
> "1970-01-01T00:00:00Z" entries?
>
> Is this somehow related to Trie fields and how they are indexed?
Yes, it's due
ed, so the term counts dont add up (how could I have more than
22404 terms if I only have 22404 documents). Why multiple
"1970-01-01T00:00:00Z" entries?
Is this somehow related to Trie fields and how they are indexed?
Thanks!
--
View this message in context:
http://lucene.472066.n3.nabb
: q=reference:"4-1.2"
:
: the value is a text, but the following is indexed as a number (e.g.:
: 004001002, where "4" becomes "004", and 1 becomes "001", and 2 "002"),
depnding on how you look at it, you could implment this as
one of two plugins:
1) if you consider this a special form of query
HI All,
I was wondering if someone could point to a direction on how to
implement a "rewrite" for the value on trie field (long) on query
time.
Example, considering the query:
q=reference:"4-1.2"
the value is a text, but the following is indexed as a number (e.g.:
00400100
nd max val should happen in constant time
:complexity.
Trie fields are encoded such that the "min" numeric value gets the "min"
Term value, and the "max" numeric value gets the "max" Term value, but
they are still just Terms, so finding the "max&
Hello,
I am trying to normalize values of a certain field, and then use them in a
function query. For that I need to know the maximum and minimum values the
field gets. I am thinking of using the scale(x, minTarget, maxTarget) query
function, but i read in solr book (Solr 1.4 enterprise search ser
Great explanation. Thanks
On 5/13/11 8:25 AM, Jonathan Rochkind wrote:
Well, let's be clear about what we're talking about. The suggested numeric and
date fields in the current Solr example schema are in fact ALL Trie based
fields.
http://svn.apache.org/viewvc/lucene/dev/trunk/so
Well, let's be clear about what we're talking about. The suggested numeric and
date fields in the current Solr example schema are in fact ALL Trie based
fields.
http://svn.apache.org/viewvc/lucene/dev/trunk/solr/example/solr/conf/schema.xml?view=markup
I don't think there is
When should one use Trie fields over the standard fields? What aret the
pro's and con's of each?
Thanks
asses.
Thanks,
-Craig
-Original Message-
From: ysee...@gmail.com [mailto:ysee...@gmail.com] On Behalf Of Yonik Seeley
Sent: Wednesday, 20 April 2011 11:19 PM
To: solr-user@lucene.apache.org
Subject: Re: Creating a TrieDateField (and other Trie fields) from Lucene
Java
On Tue, Apr 19, 2011
On Tue, Apr 19, 2011 at 11:17 PM, Craig Stires wrote:
> The barrier I have is that I need to build this offline (without using a
> solr server, solrconfig.xml, or schema.xml)
This is pretty unusual... can you share your use case?
Solr can also be run in embedded mode if you can't run a stand-alon
Wanted to share this, as I've seen a couple discussions on different boards.
The solution has been either:
1. use the solrj client
2. import as csv
3. use the streamingupdatesolrserver
The barrier I have is that I need to build this offline (without using a
solr server, solrconfig.xml, or
.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
> > at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> > at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> > at
> org.apa
e(StandardHostValve.java:127)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
&
with the use
of Trie fields (which we have just started using) as the Exception is being
thrown initially from a class called NumericUtils:
http://www.jarvana.com/jarvana/view/org/apache/lucene/lucene-core/3.0.2/lucene-core-3.0.2-sources.jar!/org/apache/lucene/util/NumericUtils.java?format=ok
I
thank you guys for the answers... now I have to check / read some docs ;)
Rich
-Original Message-
From: Simon Willnauer [mailto:simon.willna...@googlemail.com]
Sent: Tuesday, September 21, 2010 23:00
To: solr-user@lucene.apache.org
Subject: Re: trie
2010/9/21 Péter Király :
> You
:
>> is there any good tutorial how to use and what is trie? what I found on the
>> net is really blurry.
>>
>> rgeards,
>> Rich
>>
>>
>> __ Information from ESET NOD32 Antivirus, version of virus signature
>> database 5419 (20100
http://en.wikipedia.org/wiki/Trie explains pretty well what a trie is
and what it's used for. In search, suffix trees (which are a special
case of tries) are especially important.
On 21 September 2010 21:34, Papp Richard wrote:
> is there any good tutorial how to use and what is trie
You can read about it in Lucene in Action second edition.
Péter
2010/9/21 Papp Richard :
> is there any good tutorial how to use and what is trie? what I found on the
> net is really blurry.
>
> rgeards,
> Rich
>
>
> __ Information from ESET NOD32 Antivirus, ve
is there any good tutorial how to use and what is trie? what I found on the
net is really blurry.
rgeards,
Rich
__ Information from ESET NOD32 Antivirus, version of virus signature
database 5419 (20100902) __
The message was checked by ESET NOD32 Antivirus.
http
On Mon, Dec 21, 2009 at 5:37 PM, Marc Sturlese wrote:
>
> Should sortMissingLast param be working on trie-fields?
>
>
Nope, trie fields do not support sortMissingFirst or sortMissingLast.
--
Regards,
Shalin Shekhar Mangar.
On Thu, Oct 1, 2009 at 2:54 PM, Lance Norskog wrote:
> Trie fields also do not support faceting.
Only those that index multiple tokens per value to speed up range queries.
> They also take more ram in
> some operations.
Should be less memory on average.
-Yonik
http://www.lucidimagin
On Thu, Oct 1, 2009 at 11:09 PM, Steve Conover wrote:
>> Not in time for 1.4, but yes they will eventually get it.
>> It has to do with the representation... currently we can't tell
>> between a 0 and "missing".
>
> Hmm. So does that mean that a query for l
> Not in time for 1.4, but yes they will eventually get it.
> It has to do with the representation... currently we can't tell
> between a 0 and "missing".
Hmm. So does that mean that a query for latitudes, stored as trie
floats, from -10 to +10 matches documents with
.. currently we can't tell
between a 0 and "missing".
> Do you all think that a reasonable strategy is to use a copyField and
> use "s" fields for sorting (only), and trie for everything else?
If you don't need the fast range queries, use the "s" fields
Trie fields also do not support faceting. They also take more ram in
some operations.
Given these defects, I'm not sure that promoting tries as the default
is appropriate at this time. (I'm sure this is an old argument.:)
On Thu, Oct 1, 2009 at 7:39 AM, Steve Conover wrote:
> I
I just noticed this comment in the default schema:
Does that mean TrieFields are never going to get sortMissingLast?
Do you all think that a reasonable strategy is to use a copyField and
use "s" fields for sorting (only), and trie for everything else?
On Wed, Sep 30, 2009 at 10:59
Am I correct in thinking that trie fields don't support
sortMissingLast (my tests show that they don't). If not, is there any
plan for adding it in?
Regards,
Steve
e any problem.
>>
>> Are you using a recent nightly build?
>> See the example schema of a recent nightly build for the correct way
>> to define a Trie based field - the article / blog may be out of date.
>>
>> Here's what I used to test the example dat
PM, Yonik Seeley wrote:
> I can't reproduce any problem.
>
> Are you using a recent nightly build?
> See the example schema of a recent nightly build for the correct way
> to define a Trie based field - the article / blog may be out of date.
>
> Here's what I used to te
I can't reproduce any problem.
Are you using a recent nightly build?
See the example schema of a recent nightly build for the correct way
to define a Trie based field - the article / blog may be out of date.
Here's what I used to test the example data:
http://localhost:8983/sol
on my test index:
q=datetime:[NOW/DAY-1YEAR TO NOW/DAY]
i get numFound="1031524" (don't worry about the ordering yet)..
then, if I do the following on my trie date field:
q=tdatetime:[NOW/DAY-1YEAR TO NOW/DAY]
i get numFound="0"
Where did I go wrong? (And yes, both fields are
Trie has a custom parser that can load the FieldCache for sorting. Its
basically a built in type now, that supports fieldcache, sorting, stored
fields, etc.
On Sat, Jul 4, 2009 at 3:27 PM, Chris Hostetter wrote:
>
> : My data are library call numbers, normalized to be comparable, resultin
got two or three for each of my
: 6M documents and on a 32-bit machine I run out of heap.
:
: Another option would be to turn them into longs (using roughly 56 bits of
: the 64 bit space) and use a trie type. Is there any sort of a win involved
: there?
I don't think Trie fields can be used
I've having trouble understanding how the Trie type compares (speed- and
memory-wise) with dealing with long *string* (as opposed to integers).
My data are library call numbers, normalized to be comparable, resulting in
(maximum) 21-character strings of the form "RK 052180H359~999
I'd just change it to true and see what happens. It won't break
anything.
-Grant
On Jun 11, 2009, at 10:50 PM, Peter Wolanin wrote:
Looking at the new examples of solr.TrieField
http://svn.apache.org/repos/asf/lucene/solr/trunk/example/solr/conf/schema.xml
I see that all have indexed="tru
Looking at the new examples of solr.TrieField
http://svn.apache.org/repos/asf/lucene/solr/trunk/example/solr/conf/schema.xml
I see that all have indexed="true" stored="false" in the field tpye
definition. Does this mean that yo cannot ever store a value for one
of these fields? I.e. if I want t
> > I am still using Solr 1.2 with the Lucene 2.2 that came with that version
> > of Solr. I am interested in taking advantage of the trie filtering to
> > alleviate some performance problems and was wondering how back-portable
> > these patches are?
> >
>
Trie is a
I take it by the deafening silence that this is not possible? :-)
On Mon, Jun 8, 2009 at 11:34 AM, Amit Nithian wrote:
> Hi,
> I am still using Solr 1.2 with the Lucene 2.2 that came with that version
> of Solr. I am interested in taking advantage of the trie filtering to
> al
Hi,
I am still using Solr 1.2 with the Lucene 2.2 that came with that version of
Solr. I am interested in taking advantage of the trie filtering to alleviate
some performance problems and was wondering how back-portable these patches
are?
I am also trying to understand how the Trie algorithm cuts
45 matches
Mail list logo
