lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Smith" <ssm...@mainstreamdata.com>
Subject RE: Managing a large archival (and constantly changing) database
Date Sat, 08 Jul 2006 02:01:20 GMT
Thanks to everyone who commented.  Clearly, I have a lot to think about,
but thanks for the help.

Scott

-----Original Message-----
From: Rob Staveley (Tom) [mailto:rstaveley@seseit.com] 
Sent: Friday, July 07, 2006 2:53 PM
To: java-user@lucene.apache.org
Subject: RE: Managing a large archival (and constantly changing)
database

Aha, OK that makes sense. Likewise James Pine's explanation. Thanks both
of
you.

-----Original Message-----
From: Chris Hostetter [mailto:hossman_lucene@fucit.org] 
Sent: 07 July 2006 20:40
To: java-user@lucene.apache.org
Subject: RE: Managing a large archival (and constantly changing)
database


: How can that be so? When the segments file is re-written it will
surely
: clobber the copy rather than creating a new INODE, because it has the
same
: name... wouldn't it?

if you take a look at SegmentInfos.java you'll see that an existing
segments
file is never modified.  a new segments file is created (named
creatively
"segments.new" and once it is complete, it is renamed "segments" in the
index directory (so the old inode is completley unmodified and still
accessible from the cloned directory)

: 	echo update > x/x.txt

i believe what is happening is analogous to...

        echo update > x/x.new
        mv x/x.new x/x.txt


-Hoss


---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org


Mime
View raw message