Dana,
RMI. We use it exclusively and we are able to cluster for fail-over. The
clustering complicates things quite a bit so you may not need or want it.
John G.
-Original Message-
From: DanaWhite [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 07, 2008 9:54 AM
To: java-user@lucene.apac
Alexander,
RMI. We use it exclusively and we are able to cluster for fail-over. The
clustering complicates things quite a bit so you may not need or want it.
John G.
-Original Message-
From: Alexander Aristov [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 07, 2008 10:35 AM
To: java-us
Hi,
Perhaps you can give some examples. Yes, untokenized means "full string" - it
requires an "exact match".
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
> From: Andre Rubin <[EMAIL PROTECTED]>
> To: java-user@lucene.apache.org
> Sent: Thursda
Thank you for your reply. :)
You are correct.
I did run addIndexes method after the ramWriter colse.
And It is good working and create correct index file.
Thank you very much.
Jang.
08. 8. 8, Grant Ingersoll <[EMAIL PROTECTED]>님이 작성:
>
> Lucene does this RAM/FS stuff seamlessly for you in the
Lucene does this RAM/FS stuff seamlessly for you in the background.
Just open the FSDirectory and do your indexing. If I had to guess,
though, from a quick glance, I think you should do the addIndexes
after the ramWriter close, but that's just a guess, as I haven't tried
it.
-Grant
On
hi,
I am using RamDirectory and FSDirectory for indexing documents.
I use RamDirectory as Buffer.
For example,
---
String indexDir = "d:/lucene_data/merge_test_index";
Analyzer analyzer = new StopAnalyzer();
RAMDirectory ramDir= new RAMDirectory();
IndexWriter
Hi all,
When I switched a String field from tokenized to untokenized, some
searches started not returning some obvious values. Am I missing
something on querying untokenized fields? Another question is, do I
need an Analyzer if my search is on an Untokenized field, wouldn't the
search be based on
It's also possible to create your own code that uses FieldsReader and
FieldsWriter (both in org.apache.lucene.index) directly to create new
fdx/fdt files, with the date fixed on each document. You'd have to
enumerate over all segments in your index, create a FieldsReader
instance on each
Robert Stewart wrote:
Given an existing index, is there any way to update the value of a
particular field across all documents, without deleting/re-indexing
documents? For instance, if I have a date field, and I need to
offset all dates based on change to stored time zone (subtract 12
hours from
Given an existing index, is there any way to update the value of a particular
field across all documents, without deleting/re-indexing documents? For
instance, if I have a date field, and I need to offset all dates based on
change to stored time zone (subtract 12 hours from each value). The so
Thanks a lot for your responses...
I have tried the HitCollector and throw an exception when the limit of hits is
reached...
It works fine and the search time is really reduce when there is a lot of docs
which are matching the query...
I did that :
public class CountCollector extends HitCollec
On Thu, Aug 7, 2008 at 11:57 AM, Neeraj Gupta <[EMAIL PROTECTED]> wrote:
> A Gentle Reminder! Any Solution around this problem?
Lucky you, it's already been solved :-)
Seriously though, I think you are making some incorrect assumptions
about how Lucene works. Lucene does not retrieve all 50K doc
Hi
Mount the file system of that machine to another one as a network share. But
I don;t think it would be optimal.
Alexander
2008/8/7 DanaWhite <[EMAIL PROTECTED]>
>
> Hello,
>
> I have two machines on the same network, but I want to use one machine to
> search an index located on the file syst
I guess the starting point would be to have the IndexSearcher to take
a URI as the path to index (I don't think such a constructor exists)
than the ones currently available. This might also call for some
security policy to be in place to restrict access.
Otherwise, J2EE perhaps ?
Good question !
A Gentle Reminder! Any Solution around this problem?
Regards
-Neeraj
Thank you for the reply, As you said
Sure, just iterate over the first 100 entries in your Hits object
It means before Iteration Lucene has already spent time and memory in
finding all the 50k documents and sorting them,
Hello,
I have two machines on the same network, but I want to use one machine to
search an index located on the file system of the other machine.
Any ideas on how to achieve this?
Thanks
Dana
--
View this message in context:
http://www.nabble.com/Searching-an-Index-on-Another-Machine-tp188736
Thanks Mark and Jason for your responses and your contrib to Lucene. I will try
to dig into them and incorporate the ideas into my app. Thanks again!
Alex
>-Original Message-
>From: Jason Rutherglen [mailto:[EMAIL PROTECTED]
>Sent: Thursday, August 07, 2008 10:07 AM
>To: java-user@lucen
Thanks for you reply Glen
But I saw this solution before.
And as I said before, moving is very often operation and storing
full path can cost additional unwanted operations and therefore
it's not a desirable solution.
Sergey Kabashnyuk
eXo Platform SAS
There are a number of ways to do this.
There are a number of ways to do this. Here is one:
Lose the parentid field (unless you have other reasons to keep it).
Add a field fullName, and a field called depth :
doc1
fullName: state
depth: 0
doc2
fullName: state/department
depth:1
doc3
fullName: state/department/Boston
depth: 2
doc4
ful
The contrib realtime search patch enables the functionality you described.
https://issues.apache.org/jira/browse/LUCENE-1313
On Wed, Aug 6, 2008 at 7:45 PM, Alex Wang <[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> To allow mutilple users concurrently add, delete docs and at the same time
> search the
Hello
I have such document structure
doc1
id - 1
parentid - 0
name -state
doc2
id - 2
parentid - 1
name - department
doc3
id - 3
parentid - 2
name – Boston
doc4
id - 4
parentid - 2
name – Opera
Dear List,
I have a rather big index around 20gb. My documents have a unique id
that I store in in an untokenized field.
Using an IndexReader I delete documents by term using the id. The
applications tries to batch as many delete operations as possible for
this.
The applications runs on a 8Core
Doron Cohen wrote:
Nothing built in that I'm aware of will do this, but it can be done by
searching with your own HitCollector.
There is a related feature - stop search after a specified time - using
TimeLimitedCollector.
It is not released yet, see issue LUCENE-997.
In short, the collector's col
Yes markrmiller,the order is important
then
TokenStream result = new StandardTokenizer(reader);
result = new StandardFilter(result);
result = new StopFilter(result, stoptable);
result = new ISOLatin1AccentFilter(result);
result = new FrenchStemFilter(result, excltable);
Nothing built in that I'm aware of will do this, but it can be done by
searching with your own HitCollector.
There is a related feature - stop search after a specified time - using
TimeLimitedCollector.
It is not released yet, see issue LUCENE-997.
In short, the collector's collect() method is invo
When combining any sub queries, a scorer has at least two things to decide:
which docs to match, and once matched, how to score. Boolean Queries applies
specific logics for this, and some queries allow some control of the way to
score. For current CustomScoreQuery things are more straightforward -
Also, since the docs are so regular from a line file, to gain indexing
throughput you can re-use the Document & Field instances, and inside
the while loop just use Field.setValue(...) to change the value per
document.
Mike
Anshum wrote:
Hi,
How about just opening a file and parsing thr
Hello
Is there a way to stop the search process when a given number of hits is
reached?
I have a counter feature which displays how many docs match a query.
This counter is blocked; I mean that if there are more than 500 docs, it will
just display "more than 500".
I don't care about the exact
28 matches
Mail list logo
