Re: SRND query
On Wednesday 26 April 2006 00:40, Boris Galitsky wrote: > Hello > > > We need to construct nested span queries, and it seems like SrndQuery > is a good way to do it. > > Are there examples available for SrndQueries? How to construct them > (is it using QueryParser?). > Where to get Surround Parser? > > How to run them? Have a look in the svn repository, in the contrib/surround/src/test directory is junit test code exercising the surround query parser. Iirc in the contrib area there is also an xml query parser that allows xml structured queries, but at the moment I don't know precisely where that is. Regards, Paul Elschot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: boosting fields
25 apr 2006 kl. 19.34 skrev Doug Cutting:
karl wettin wrote:
This could lead me to believe I can use different boost for
fields with the same name within one document.
You can. The values are multiplied to produce the final boost
value for the field. This is described in:
http://lucene.apache.org/java/docs/api/org/apache/lucene/document/
Field.html#setBoost(float)
It's not really the same thing as I tried to describe though. In the
end it is the same boost for all field values. I would personally
prefer to set that manually per unique field name. I have a hard time
to figure out why I want to add multiple boosts and then normalise
them. Is there some feature I missed?
How about refactoring fields to something like:
[Document](fieldName)<#> {0..1} ->[Field +boost]<#> {0..*}
-> [FieldValue +store +index +termVector]
That would be a big, incompatible change to one of Lucene's primary
APIs, no?
Not if I got it right in my head. Then it's really just a matter of
handling deprication. The field-methods in Document could be the same.
Long-term, an API which supports per token boosting will probably
prove useful, as a part of #11 on http://wiki.apache.org/jakarta-
lucene/Lucene2Whiteboard. When this happens it would probably be
worth considering making the change you suggest, but I'm not sure
it would be worth it before that.
I've wanted that feature a few times. Let me know if there is
something I can do to help when the time is right.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: boosting fields
karl wettin wrote:
This could lead me to believe I can use different boost for fields with
the same name within one document.
You can. The values are multiplied to produce the final boost value for
the field. This is described in:
http://lucene.apache.org/java/docs/api/org/apache/lucene/document/Field.html#setBoost(float)
But you're right, that's not entirely intuitive.
How about refactoring fields to something like:
[Document](fieldName)<#> {0..1} ->[Field +boost]<#> {0..*} ->
[FieldValue +store +index +termVector]
That would be a big, incompatible change to one of Lucene's primary
APIs, no? Long-term, an API which supports per token boosting will
probably prove useful, as a part of #11 on
http://wiki.apache.org/jakarta-lucene/Lucene2Whiteboard. When this
happens it would probably be worth considering making the change you
suggest, but I'm not sure it would be worth it before that.
Doug
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
SRND query
Hello We need to construct nested span queries, and it seems like SrndQuery is a good way to do it. Are there examples available for SrndQueries? How to construct them (is it using QueryParser?). Where to get Surround Parser? How to run them? Best regards Boris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (LUCENE-555) Index Corruption
Ok than
indexer indexes to separate directory (sequence of dir, e.g. 1/ 2/ 3/
4/) with create=true. [transaction log]
than merges newly created index to 'for-search' index.
backup is copy of 'for-search' index
than rollforward is IndexWriter addIndexes(...) newer than backup image.
rollbackward to DATE is rollforward to date etc.
indexed data kept as chunk of xml files.
also there is no problem to have 'for-search' indexes 0/ 1/ directory
and use soft link
current and old.On success of following swap those links.
IndexWriter path=old/ create=true
IndexWriter.addIndexes(new Directory[] { current, 5/ }
Doug has written somewhere how technorati achived delta-backups.
There are a lot of way achive fail-over.
PS: MySQL :) try to work with innodb and move system time backward.
- Like all modern database programs, there has to be a way to repair an index.
Period.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-555) Index Corruption
[ http://issues.apache.org/jira/browse/LUCENE-555?page=comments#action_12376331 ] Chuck Williams commented on LUCENE-555: --- Dan, I don't know if you are still watching this, but in addition to Doug's point about how Lucene changes, there is a second important consideration to keep in mind. Lucene is a search library, not an enterprise search application. If you are looking for the latter, you might want to check out something like SOLR. The existence of SOLR demonstrates the difference. There are many successful applications based on Lucene for a wide range of uses. Many major products and web sites are based on Lucene. As Lucene is a library, it supports a wide range of use cases. The beauty of the library is that it is solid, robust, well exercised through use and open source review/contribution, and is well-designed for specialization into different applications. Journaling and recovery are useful capabilities, but I hold to the position that the job of the library is to never corrupt the index. Journalizing and recovery should be optional add-ons for those applications that need them. For my current application, for example, total index corruption can be resolved by reindexing from an external persistent repository. My one requirement is to know if data is lost, and if it is a small amount of data, to be able to identify what was lost. Whence, a limited journaling capability that focuses on recovery of data held in RAM and not yet committed to disk when a crash occurs. What you found is a bug in optimize, a quite surprising one at that. Please take the time to help track it down. > Index Corruption > > > Key: LUCENE-555 > URL: http://issues.apache.org/jira/browse/LUCENE-555 > Project: Lucene - Java > Type: Bug > Components: Index > Versions: 1.9 > Environment: Linux FC4, Java 1.4.9 > Reporter: dan > Priority: Critical > > Index Corruption > > output > java.io.FileNotFoundException: ../_aki.fnm (No such file or directory) > at java.io.RandomAccessFile.open(Native Method) > at java.io.RandomAccessFile.(RandomAccessFile.java:204) > at > org.apache.lucene.store.FSIndexInput$Descriptor.(FSDirectory.java:425) > at org.apache.lucene.store.FSIndexInput.(FSDirectory.java:434) > at org.apache.lucene.store.FSDirectory.openInput(FSDirectory.java:324) > at org.apache.lucene.index.FieldInfos.(FieldInfos.java:56) > at > org.apache.lucene.index.SegmentReader.initialize(SegmentReader.java:144) > at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:129) > at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:110) > at > org.apache.lucene.index.IndexWriter.mergeSegments(IndexWriter.java:674) > at > org.apache.lucene.index.IndexWriter.mergeSegments(IndexWriter.java:658) > at org.apache.lucene.index.IndexWriter.optimize(IndexWriter.java:517) > > input > - I open an index, I read, I write, I optimize, and eventually the above > happens. The index is unusable. > - This has happened to me somewhere between 20 and 30 times now - on indexes > of different shapes and sizes. > - I don't know the reason. But, the following requirement applies regardless. > > requirement > - Like all modern database programs, there has to be a way to repair an > index. Period. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Driver about ACID requirements for Lucene (Re: [jira] Commented: (LUCENE-555))
--- "dan (JIRA)" <[EMAIL PROTECTED]> wrote:
> while ( myopicEngineerStillDoesntGetIt)
> {
>
> case(1)
> {
> A small business running MySQL has a travelling
>
> case(2)
> {
> Same scenario. How does team Lucene respond? If you
Dan, do us all a favor and please figure out the
difference between a DATABASE and INDEXING ENGINE, and
quit whining.
Lucene is latter, MySQL former: you can not and should
not expect same feature set from the two. If you need
ACID, use a database. If you need fast full text
search capability, use latter. Although some DBs
bundle full text indexing packages, they are not part
of the DB engine.
If you are storing important (primary) data in Lucene
index, you are just clueless.
There are many ways to implement recoverability of
Lucene indexes; including using BDB backend or having
versioned copies of index files (instead of modifying
existing index as is, make a copy, modify it, flip
when done). But it is just downright silly to demand
database features from a non-database: the core to
good products is focusing on core features.
Catastrophic failure recovery is not a core feature
for indexing engines.
-+ Tatu +-
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-555) Index Corruption
[ http://issues.apache.org/jira/browse/LUCENE-555?page=comments#action_12376319 ] Andi Vajda commented on LUCENE-555: --- There is an implementation of the Lucene index store that is backed up by Berkeley DB. Take a look at the 'db' contrib area: http://svn.apache.org/repos/asf/lucene/java/trunk/contrib/db/ Using this you can bracket index changes with transaction. Should the cord be pulled, you can use Berkeley DB's recovery mechanisms. > Index Corruption > > > Key: LUCENE-555 > URL: http://issues.apache.org/jira/browse/LUCENE-555 > Project: Lucene - Java > Type: Bug > Components: Index > Versions: 1.9 > Environment: Linux FC4, Java 1.4.9 > Reporter: dan > Priority: Critical > > Index Corruption > > output > java.io.FileNotFoundException: ../_aki.fnm (No such file or directory) > at java.io.RandomAccessFile.open(Native Method) > at java.io.RandomAccessFile.(RandomAccessFile.java:204) > at > org.apache.lucene.store.FSIndexInput$Descriptor.(FSDirectory.java:425) > at org.apache.lucene.store.FSIndexInput.(FSDirectory.java:434) > at org.apache.lucene.store.FSDirectory.openInput(FSDirectory.java:324) > at org.apache.lucene.index.FieldInfos.(FieldInfos.java:56) > at > org.apache.lucene.index.SegmentReader.initialize(SegmentReader.java:144) > at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:129) > at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:110) > at > org.apache.lucene.index.IndexWriter.mergeSegments(IndexWriter.java:674) > at > org.apache.lucene.index.IndexWriter.mergeSegments(IndexWriter.java:658) > at org.apache.lucene.index.IndexWriter.optimize(IndexWriter.java:517) > > input > - I open an index, I read, I write, I optimize, and eventually the above > happens. The index is unusable. > - This has happened to me somewhere between 20 and 30 times now - on indexes > of different shapes and sizes. > - I don't know the reason. But, the following requirement applies regardless. > > requirement > - Like all modern database programs, there has to be a way to repair an > index. Period. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-555) Index Corruption
[ http://issues.apache.org/jira/browse/LUCENE-555?page=comments#action_12376313 ] Yonik Seeley commented on LUCENE-555: - Dan, I am interested in the source if index corruption. If you can share a test that reproduces this, it would be helpful. > Index Corruption > > > Key: LUCENE-555 > URL: http://issues.apache.org/jira/browse/LUCENE-555 > Project: Lucene - Java > Type: Bug > Components: Index > Versions: 1.9 > Environment: Linux FC4, Java 1.4.9 > Reporter: dan > Priority: Critical > > Index Corruption > > output > java.io.FileNotFoundException: ../_aki.fnm (No such file or directory) > at java.io.RandomAccessFile.open(Native Method) > at java.io.RandomAccessFile.(RandomAccessFile.java:204) > at > org.apache.lucene.store.FSIndexInput$Descriptor.(FSDirectory.java:425) > at org.apache.lucene.store.FSIndexInput.(FSDirectory.java:434) > at org.apache.lucene.store.FSDirectory.openInput(FSDirectory.java:324) > at org.apache.lucene.index.FieldInfos.(FieldInfos.java:56) > at > org.apache.lucene.index.SegmentReader.initialize(SegmentReader.java:144) > at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:129) > at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:110) > at > org.apache.lucene.index.IndexWriter.mergeSegments(IndexWriter.java:674) > at > org.apache.lucene.index.IndexWriter.mergeSegments(IndexWriter.java:658) > at org.apache.lucene.index.IndexWriter.optimize(IndexWriter.java:517) > > input > - I open an index, I read, I write, I optimize, and eventually the above > happens. The index is unusable. > - This has happened to me somewhere between 20 and 30 times now - on indexes > of different shapes and sizes. > - I don't know the reason. But, the following requirement applies regardless. > > requirement > - Like all modern database programs, there has to be a way to repair an > index. Period. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-555) Index Corruption
[ http://issues.apache.org/jira/browse/LUCENE-555?page=comments#action_12376310 ] Otis Gospodnetic commented on LUCENE-555: - Hillarious. Very constructive, Dan. Hint: somebody already implemented transaction support for Lucene a while back. > Index Corruption > > > Key: LUCENE-555 > URL: http://issues.apache.org/jira/browse/LUCENE-555 > Project: Lucene - Java > Type: Bug > Components: Index > Versions: 1.9 > Environment: Linux FC4, Java 1.4.9 > Reporter: dan > Priority: Critical > > Index Corruption > > output > java.io.FileNotFoundException: ../_aki.fnm (No such file or directory) > at java.io.RandomAccessFile.open(Native Method) > at java.io.RandomAccessFile.(RandomAccessFile.java:204) > at > org.apache.lucene.store.FSIndexInput$Descriptor.(FSDirectory.java:425) > at org.apache.lucene.store.FSIndexInput.(FSDirectory.java:434) > at org.apache.lucene.store.FSDirectory.openInput(FSDirectory.java:324) > at org.apache.lucene.index.FieldInfos.(FieldInfos.java:56) > at > org.apache.lucene.index.SegmentReader.initialize(SegmentReader.java:144) > at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:129) > at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:110) > at > org.apache.lucene.index.IndexWriter.mergeSegments(IndexWriter.java:674) > at > org.apache.lucene.index.IndexWriter.mergeSegments(IndexWriter.java:658) > at org.apache.lucene.index.IndexWriter.optimize(IndexWriter.java:517) > > input > - I open an index, I read, I write, I optimize, and eventually the above > happens. The index is unusable. > - This has happened to me somewhere between 20 and 30 times now - on indexes > of different shapes and sizes. > - I don't know the reason. But, the following requirement applies regardless. > > requirement > - Like all modern database programs, there has to be a way to repair an > index. Period. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-555) Index Corruption
[ http://issues.apache.org/jira/browse/LUCENE-555?page=comments#action_12376309 ] Doug Cutting commented on LUCENE-555: - Calling folks names probably won't help your agenda. Running away probably won't help your agenda either. What might help it it is calm, polite, persistent engagement. Lucene is changed primarily by folks who use Lucene. Other users are telling you that they don't personally require this sort of recovery. Perhaps that's even a self-defining characteristic: if they needed it then they wouldn't be using Lucene. So, if you need this in Lucene, the best way to get it added is to help add it. If you're not interested in helping, then this will probably have to wait until someone else who needs it comes along and is willing to make it happen. So, if you want to help, examine the file formats document and make a proposal. Then, if it looks like it might work, contribute a patch that implements it. Perhaps you'll be able to identify some collaborators to help out. Perhaps not. That's the way Lucene changes. > Index Corruption > > > Key: LUCENE-555 > URL: http://issues.apache.org/jira/browse/LUCENE-555 > Project: Lucene - Java > Type: Bug > Components: Index > Versions: 1.9 > Environment: Linux FC4, Java 1.4.9 > Reporter: dan > Priority: Critical > > Index Corruption > > output > java.io.FileNotFoundException: ../_aki.fnm (No such file or directory) > at java.io.RandomAccessFile.open(Native Method) > at java.io.RandomAccessFile.(RandomAccessFile.java:204) > at > org.apache.lucene.store.FSIndexInput$Descriptor.(FSDirectory.java:425) > at org.apache.lucene.store.FSIndexInput.(FSDirectory.java:434) > at org.apache.lucene.store.FSDirectory.openInput(FSDirectory.java:324) > at org.apache.lucene.index.FieldInfos.(FieldInfos.java:56) > at > org.apache.lucene.index.SegmentReader.initialize(SegmentReader.java:144) > at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:129) > at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:110) > at > org.apache.lucene.index.IndexWriter.mergeSegments(IndexWriter.java:674) > at > org.apache.lucene.index.IndexWriter.mergeSegments(IndexWriter.java:658) > at org.apache.lucene.index.IndexWriter.optimize(IndexWriter.java:517) > > input > - I open an index, I read, I write, I optimize, and eventually the above > happens. The index is unusable. > - This has happened to me somewhere between 20 and 30 times now - on indexes > of different shapes and sizes. > - I don't know the reason. But, the following requirement applies regardless. > > requirement > - Like all modern database programs, there has to be a way to repair an > index. Period. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-555) Index Corruption
[ http://issues.apache.org/jira/browse/LUCENE-555?page=comments#action_12376308 ] robert engels commented on LUCENE-555: -- Dan, please let us know what company you work for so we can avoid that place like the plague. You are obviously having a bad day, year, life... If you took the time to actually READ the comments, you would realize that for MOST users of Lucene the performance overhead that would be required in EVERY CASE in order to allow index recovery IN THE RARE CASE is not worth it. For MOST users of Lucene the index can be regenerated if the index should become corrupt - similar to how MySQL "rebuilds" the database - just a different process. MySQL cannot recover missing data if the data disk blocks become corrupt - after recovery those records will be gone. For MANY users this is unacceptable. MySQL can rebuild the indexes on the data, since it has the source data. With Lucene, in MOST cases, the data Lucene retains is insufficient to rebuild the index from scratch. > Index Corruption > > > Key: LUCENE-555 > URL: http://issues.apache.org/jira/browse/LUCENE-555 > Project: Lucene - Java > Type: Bug > Components: Index > Versions: 1.9 > Environment: Linux FC4, Java 1.4.9 > Reporter: dan > Priority: Critical > > Index Corruption > > output > java.io.FileNotFoundException: ../_aki.fnm (No such file or directory) > at java.io.RandomAccessFile.open(Native Method) > at java.io.RandomAccessFile.(RandomAccessFile.java:204) > at > org.apache.lucene.store.FSIndexInput$Descriptor.(FSDirectory.java:425) > at org.apache.lucene.store.FSIndexInput.(FSDirectory.java:434) > at org.apache.lucene.store.FSDirectory.openInput(FSDirectory.java:324) > at org.apache.lucene.index.FieldInfos.(FieldInfos.java:56) > at > org.apache.lucene.index.SegmentReader.initialize(SegmentReader.java:144) > at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:129) > at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:110) > at > org.apache.lucene.index.IndexWriter.mergeSegments(IndexWriter.java:674) > at > org.apache.lucene.index.IndexWriter.mergeSegments(IndexWriter.java:658) > at org.apache.lucene.index.IndexWriter.optimize(IndexWriter.java:517) > > input > - I open an index, I read, I write, I optimize, and eventually the above > happens. The index is unusable. > - This has happened to me somewhere between 20 and 30 times now - on indexes > of different shapes and sizes. > - I don't know the reason. But, the following requirement applies regardless. > > requirement > - Like all modern database programs, there has to be a way to repair an > index. Period. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-555) Index Corruption
[
http://issues.apache.org/jira/browse/LUCENE-555?page=comments#action_12376306 ]
dan commented on LUCENE-555:
How about some engineering satire to spell it out for you nerds? [Doesn't apply
to you Chuck]
public void businessRealityCheck()
{
boolean myopicEngineerStillDoesntGetIt = true;
while ( myopicEngineerStillDoesntGetIt)
{
case(1)
{
A small business running MySQL has a travelling salesman who trips and pulls
the power cord - the database is corrupt. The cause had nothing to do with the
software whatsoever. How does team MySQL respond? The say with enthusiasm "run
this recovery program with these parameters..." And guess what? It just works!
The database is recovered. MySQL moves to the top of the class.
}
case(2)
{
Same scenario. How does team Lucene respond? If you are Robert, you say "I
think Dan is way off base." If you are Otis, you retort "I agree with Robert."
And all others sing the chorus. LOL. You could get a gig at The Comedy Club
with this material guys. It's hilarious.
}
if ( case(1) == case(2))
myopicEngineerStillDoesntGetIt = true;
else
break;
}
}
I'm off this express train to Pretend Town. Close this issue. Pretend that
recovery isn't critical. And enjoy your train ride home.
> Index Corruption
>
>
> Key: LUCENE-555
> URL: http://issues.apache.org/jira/browse/LUCENE-555
> Project: Lucene - Java
> Type: Bug
> Components: Index
> Versions: 1.9
> Environment: Linux FC4, Java 1.4.9
> Reporter: dan
> Priority: Critical
>
> Index Corruption
> > output
> java.io.FileNotFoundException: ../_aki.fnm (No such file or directory)
> at java.io.RandomAccessFile.open(Native Method)
> at java.io.RandomAccessFile.(RandomAccessFile.java:204)
> at
> org.apache.lucene.store.FSIndexInput$Descriptor.(FSDirectory.java:425)
> at org.apache.lucene.store.FSIndexInput.(FSDirectory.java:434)
> at org.apache.lucene.store.FSDirectory.openInput(FSDirectory.java:324)
> at org.apache.lucene.index.FieldInfos.(FieldInfos.java:56)
> at
> org.apache.lucene.index.SegmentReader.initialize(SegmentReader.java:144)
> at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:129)
> at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:110)
> at
> org.apache.lucene.index.IndexWriter.mergeSegments(IndexWriter.java:674)
> at
> org.apache.lucene.index.IndexWriter.mergeSegments(IndexWriter.java:658)
> at org.apache.lucene.index.IndexWriter.optimize(IndexWriter.java:517)
> > input
> - I open an index, I read, I write, I optimize, and eventually the above
> happens. The index is unusable.
> - This has happened to me somewhere between 20 and 30 times now - on indexes
> of different shapes and sizes.
> - I don't know the reason. But, the following requirement applies regardless.
> > requirement
> - Like all modern database programs, there has to be a way to repair an
> index. Period.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: boosting fields
25 apr 2006 kl. 18.56 skrev karl wettin:
How about refactoring fields to something like:
[Document](fieldName)<#> {0..1} ->[Field +boost]<#> {0..*} -
>[FieldValue +store +index +termVector]
instead of as now:
[Document](fieldName)<#> {0..1} ->[Field +boost +store +index
+termVector]
Oups.
instead of as now:
[Document](fieldName)<#> {0..*} ->[Field +boost +store +index
+termVector]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
boosting fields
I don't like how fields are configured.
Document doc = new Document();
Field f;
f = new Field("foo", "bar tzar", Field.Store.NO,
Field.Index.TOKENIZED, Field.TermVector.YES);
f.setBoost(1.5f);
doc.add(f);
f = new Field("foo", "blah yada", Field.Store.NO,
Field.Index.TOKENIZED, Field.TermVector.WITH_POSITIONS);
f.setBoost(2f);
doc.add(f);
This could lead me to believe I can use different boost for fields
with the same name within one document. I guess it is nice that I can
set it up so that different subsets of the terms are stored a
specific way in the term vector, even though I never had to use it.
But the boosts are stored by field name, right? There are no
constraints in the code. I would at least expect a warning when
indexing above document.
How about refactoring fields to something like:
[Document](fieldName)<#> {0..1} ->[Field +boost]<#> {0..*} ->
[FieldValue +store +index +termVector]
instead of as now:
[Document](fieldName)<#> {0..1} ->[Field +boost +store +index
+termVector]
I would not mind if it worked the way the design implies, but it
doesn't. Right?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn.apache.org (80) is down!
Thanks Doug, I didn't know about monitoring server. Lukas On 4/25/06, Doug Cutting <[EMAIL PROTECTED]> wrote: > You can check the status of Apache servers here: > > http://monitoring.apache.org/status/ > > If errors are shown there, then Apache's infrastructure folks already > know about the problem. So please only report problems if they don't > show on that page. > > It looks like minotaur is back up now. > > Doug > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn.apache.org (80) is down!
You can check the status of Apache servers here: http://monitoring.apache.org/status/ If errors are shown there, then Apache's infrastructure folks already know about the problem. So please only report problems if they don't show on that page. It looks like minotaur is back up now. Doug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn.apache.org (80) is down!
Same here. Lukas Vlcek wrote: Hi, I noticed that svn.apache.org went down. Lukas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn.apache.org (80) is down!
Hi, I noticed that svn.apache.org went down. Lukas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Lucene Eclipse Integration
Hi, I want to create a back-of-book type index for Eclipse help (not available by default). This index will list all indexed terms such that the indexed term may be clicked and the original document displayed (as in MS style help systems). Where should I begin? The first thing I suppose would be, how do I access the indexed terms (using Lucene's API) and have them e.g. display on a HTML page with hyperlinks to the original doc. Any help appreciated. -- View this message in context: http://www.nabble.com/Lucene-Eclipse-Integration-t1504322.html#a4078945 Sent from the Lucene - Java Developer forum at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
