[jira] Updated: (LUCENE-967) Add "tokenize documents only" task to contrib/benchmark
[
https://issues.apache.org/jira/browse/LUCENE-967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-967:
--
Attachment: LUCENE-967.take2.patch
New rev of this patch. Only real change is to reduce overhead
(slightly) of benchmark framework by pre-building array of PerfTasks
instead of creating new iterator for each document.
> Add "tokenize documents only" task to contrib/benchmark
> ---
>
> Key: LUCENE-967
> URL: https://issues.apache.org/jira/browse/LUCENE-967
> Project: Lucene - Java
> Issue Type: Improvement
> Components: contrib/benchmark
>Affects Versions: 2.3
>Reporter: Michael McCandless
>Assignee: Michael McCandless
>Priority: Minor
> Fix For: 2.3
>
> Attachments: LUCENE-967.patch, LUCENE-967.take2.patch
>
>
> I've been looking at performance improvements to tokenization by
> re-using Tokens, and to help benchmark my changes I've added a new
> task called ReadTokens that just steps through all fields in a
> document, gets a TokenStream, and reads all the tokens out of it.
> EG this alg just reads all Tokens for all docs in Reuters collection:
> doc.maker=org.apache.lucene.benchmark.byTask.feeds.ReutersDocMaker
> doc.maker.forever=false
> {ReadTokens > : *
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (LUCENE-836) Benchmarks Enhancements (precision/recall, TREC, Wikipedia)
[ https://issues.apache.org/jira/browse/LUCENE-836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Doron Cohen resolved LUCENE-836. Resolution: Fixed Lucene Fields: [Patch Available] (was: [New]) Committed. > Benchmarks Enhancements (precision/recall, TREC, Wikipedia) > --- > > Key: LUCENE-836 > URL: https://issues.apache.org/jira/browse/LUCENE-836 > Project: Lucene - Java > Issue Type: New Feature > Components: Other >Reporter: Grant Ingersoll >Assignee: Doron Cohen >Priority: Minor > Attachments: lucene-836.benchmark.quality.patch, > lucene-836.benchmark.quality.patch, lucene-836.benchmark.quality.patch > > > Would be great if the benchmark contrib had a way of providing > precision/recall benchmark information ala TREC. I don't know what the > copyright issues are for the TREC queries/data (I think the queries are > available, but not sure about the data), so not sure if the is even feasible, > but I could imagine we could at least incorporate support for it for those > who have access to the data. It has been a long time since I have > participated in TREC, so perhaps someone more familiar w/ the latest can fill > in the blanks here. > Another option is to ask for volunteers to create queries and make judgments > for the Reuters data, but that is a bit more complex and probably not > necessary. Even so, an Apache licensed set of benchmarks may be useful for > the community as a whole. Hmmm > Wikipedia might be another option instead of Reuters to setup as a download > for benchmarking, as it is quite large and I believe the licensing terms are > quite amenable. Having a larger collection would be good for stressing > Lucene more and would give many users a demonstration of how Lucene handles > large collections. > At any rate, this kind of information could be useful for people looking at > different indexing schemes, formats, payloads and different query strategies. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (LUCENE-836) Benchmarks Enhancements (precision/recall, TREC, Wikipedia)
[ https://issues.apache.org/jira/browse/LUCENE-836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Doron Cohen reassigned LUCENE-836: -- Assignee: Doron Cohen > Benchmarks Enhancements (precision/recall, TREC, Wikipedia) > --- > > Key: LUCENE-836 > URL: https://issues.apache.org/jira/browse/LUCENE-836 > Project: Lucene - Java > Issue Type: New Feature > Components: Other >Reporter: Grant Ingersoll >Assignee: Doron Cohen >Priority: Minor > Attachments: lucene-836.benchmark.quality.patch, > lucene-836.benchmark.quality.patch, lucene-836.benchmark.quality.patch > > > Would be great if the benchmark contrib had a way of providing > precision/recall benchmark information ala TREC. I don't know what the > copyright issues are for the TREC queries/data (I think the queries are > available, but not sure about the data), so not sure if the is even feasible, > but I could imagine we could at least incorporate support for it for those > who have access to the data. It has been a long time since I have > participated in TREC, so perhaps someone more familiar w/ the latest can fill > in the blanks here. > Another option is to ask for volunteers to create queries and make judgments > for the Reuters data, but that is a bit more complex and probably not > necessary. Even so, an Apache licensed set of benchmarks may be useful for > the community as a whole. Hmmm > Wikipedia might be another option instead of Reuters to setup as a download > for benchmarking, as it is quite large and I believe the licensing terms are > quite amenable. Having a larger collection would be good for stressing > Lucene more and would give many users a demonstration of how Lucene handles > large collections. > At any rate, this kind of information could be useful for people looking at > different indexing schemes, formats, payloads and different query strategies. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-965) Implement a state-of-the-art retrieval function in Lucene
[ https://issues.apache.org/jira/browse/LUCENE-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516185 ] Charlie Zhao commented on LUCENE-965: - Regarding the approach to compute avgDL, this patch goes like this: +float avgDL=0.0f; +for (int i=0; iD2 |D|/avgD is what we got from the suggested alternative code and D1 < D2 They have totally flipped the relationship between D1 and D2. My impression of the Axiomatic Retrieval Function is: it still tries to penalize longer doc. So maybe the alternative code is what we need? By the same token, |D| != Similarity.decodeNorm(fieldNorms[doc]). Note: since we are recovering from the norm, so avgDL and DL != their original absolute value. But they suffice for the scoring purpose. Based on Doug's previous comment, I totally agree that avgDL should be pre-computed and cached in the searcher before where the rubber meets the road. And the cost might be invisible if we warm up the searcher first. Thanks for explaining. Not sure where Doron implemented 1 / sqrt((1 - Slope) * Pivot + (Slope) * Doclen). Since LUCENE-836 looks will be committed soon. I am really excited to see which similarity function will prevail in this era. BTW, anyone would like to share how to read Lucene patches more efficiently? I mean I had hard time to make sense of those +s and -s independently from their source files. Is there a way to plug in a patch into my local source repository, so I can diff with my favorite diff tool? Thanks in advance. > Implement a state-of-the-art retrieval function in Lucene > - > > Key: LUCENE-965 > URL: https://issues.apache.org/jira/browse/LUCENE-965 > Project: Lucene - Java > Issue Type: Improvement > Components: Search >Affects Versions: 2.2 >Reporter: Hui Fang > Attachments: axiomaticFunction.patch > > > We implemented the axiomatic retrieval function, which is a state-of-the-art > retrieval function, to > replace the default similarity function in Lucene. We compared the > performance of these two functions and reported the results at > http://sifaka.cs.uiuc.edu/hfang/lucene/Lucene_exp.pdf. > The report shows that the performance of the axiomatic retrieval function is > much better than the default function. The axiomatic retrieval function is > able to find more relevant documents and users can see more relevant > documents in the top-ranked documents. Incorporating such a state-of-the-art > retrieval function could improve the search performance of all the > applications which were built upon Lucene. > Most changes related to the implementation are made in AXSimilarity, > TermScorer and TermQuery.java. However, many test cases are hand coded to > test whether the implementation of the default function is correct. Thus, I > also made the modification to many test files to make the new retrieval > function pass those cases. In fact, we found that some old test cases are not > reasonable. For example, in the testQueries02 of TestBoolean2.java, > the query is "+w3 xx", and we have two documents "w1 xx w2 yy w3" and "w1 w3 > xx w2 yy w3". > The second document should be more relevant than the first one, because it > has more > occurrences of the query term "w3". But the original test case would require > us to rank > the first document higher than the second one, which is not reasonable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-584) Decouple Filter from BitSet
[
https://issues.apache.org/jira/browse/LUCENE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516154
]
Paul Elschot commented on LUCENE-584:
-
Mark,
An easy way to keep things like BooleanFilter working could be to
introduce a subclass of Filter, say BitsFilter that adds a bits(IndexReader)
method.
This class should also implement getMatcher(), the default implementation could
be used for that initially.
Then BooleanFilter could simply be a subclass of BitsFilter, possibly without
further
modifications, although I would prefer to rename it to BooleanBitsFilter.
That would only involve some deprecation warnings in BitsFilter for the period
that Filter.bits() is deprecated.
I would not even mind cooking this up as patch to contrib.
Thoughts?
> Decouple Filter from BitSet
> ---
>
> Key: LUCENE-584
> URL: https://issues.apache.org/jira/browse/LUCENE-584
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Search
>Affects Versions: 2.0.1
>Reporter: Peter Schäfer
>Priority: Minor
> Attachments: bench-diff.txt, bench-diff.txt,
> Matcher-core20070725.patch, Matcher-default20070725.patch,
> Matcher-ground20070725.patch, Some Matchers.zip
>
>
> {code}
> package org.apache.lucene.search;
> public abstract class Filter implements java.io.Serializable
> {
> public abstract AbstractBitSet bits(IndexReader reader) throws IOException;
> }
> public interface AbstractBitSet
> {
> public boolean get(int index);
> }
> {code}
> It would be useful if the method =Filter.bits()= returned an abstract
> interface, instead of =java.util.BitSet=.
> Use case: there is a very large index, and, depending on the user's
> privileges, only a small portion of the index is actually visible.
> Sparsely populated =java.util.BitSet=s are not efficient and waste lots of
> memory. It would be desirable to have an alternative BitSet implementation
> with smaller memory footprint.
> Though it _is_ possibly to derive classes from =java.util.BitSet=, it was
> obviously not designed for that purpose.
> That's why I propose to use an interface instead. The default implementation
> could still delegate to =java.util.BitSet=.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project lucene-java (in module lucene-java) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project lucene-java has an issue affecting its community integration. This issue affects 3 projects, and has been outstanding for 18 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - eyebrowse : Web-based mail archive browsing - jakarta-lucene : Java Based Search Engine - lucene-java : Java Based Search Engine Full details are available at: http://vmgump.apache.org/gump/public/lucene-java/lucene-java/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [lucene-core-28072007.jar] identifier set to project name -DEBUG- Dependency on javacc exists, no need to add for property javacc.home. -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/lucene-java/lucene-java/gump_work/build_lucene-java_lucene-java.html Work Name: build_lucene-java_lucene-java (Type: Build) Work ended in a state of : Failed Elapsed: 39 secs Command Line: /usr/lib/jvm/java-1.5.0-sun/bin/java -Djava.awt.headless=true -Xbootclasspath/p:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dversion=28072007 -Djavacc.home=/srv/gump/packages/javacc-3.1 package [Working Directory: /srv/gump/public/workspace/lucene-java] CLASSPATH: /usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/lucene-java/build/classes/java:/srv/gump/public/workspace/lucene-java/build/classes/demo:/srv/gump/public/workspace/lucene-java/build/classes/test:/srv/gump/public/workspace/lucene-java/contrib/db/bdb/lib/db-4.3.29.jar:/srv/gump/public/workspace/lucene-java/contrib/gdata-server/lib/gdata-client-1.0.jar:/srv/gump/public/workspace/lucene-java/build/contrib/analyzers/classes/java:/srv/gump/public/workspace/lucene-java/build/contrib/ant/classes/java:/srv/gump/public/workspace/lucene-java/build/contrib/benchmark/classes/java:/srv/gump/public/workspace/lucene-java/build/contrib/db/bdb/classes/java:/srv/gump/public/workspace/lucene-java/build/contrib/db/bdb-je/classes/java:/srv/gump/public/workspace/lucene-java/build/contrib/gdata-server/classes/java:/srv/gump/public/workspace/lucene-java/build/contrib/highlighter/classes/java:/srv/gump/public/workspace/lucene-java/build/contrib/javascript/classes/java:/srv/gump/public/workspace/lucene-java/build/contrib/lucli/classes/java:/srv/gump/public/workspace/lucene-java/build/contrib/memory/classes/java:/srv/gump/public/workspace/lucene-java/build/contrib/queries/classes/java:/srv/gump/public/workspace/lucene-java/build/contrib/regex/classes/java:/srv/gump/public/workspace/lucene-java/build/contrib/similarity/classes/java:/srv/gump/public/workspace/lucene-java/build/contrib/snowball/classes/java:/srv/gump/public/workspace/lucene-java/build/contrib/spellchecker/classes/java:/srv/gump/public/workspace/lucene-java/build/contrib/surround/classes/java:/srv/gump/public/workspace/lucene-java/build/contrib/swing/classes/java:/srv/gump/public/workspace/lucene-java/build/contrib/wordnet/classes/java:/srv/gump/public/workspace/lucene-java/build/contrib/xml-query-parser/classes/java:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-trax.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/packages/junit3.8.1/junit.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/packages/je-1.7.1/lib/je.jar:/srv/gump/public/workspace/apache-commons/digester/dist/commons-digester.jar:/srv/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-28072007.jar:/srv/gump/packages/javacc-3.1/bin/lib/javacc.jar:/srv/gump/public/workspace/jline/target/jline-0.9.92-SNAPSHOT.jar:/srv/gump/packages/jtidy-04aug2000r7-dev/build/Tidy.jar:/srv/gump/public/workspace/junit/dist/junit-28072007.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-28072007.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-api-28072007.jar:/srv/gump/public/workspace/jakarta-servletapi-5/jsr154/dist/lib/servlet-api.jar:/srv/gump/packages/nekoh
[EMAIL PROTECTED]: Project lucene-java (in module lucene-java) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project lucene-java has an issue affecting its community integration. This issue affects 3 projects, and has been outstanding for 18 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - eyebrowse : Web-based mail archive browsing - jakarta-lucene : Java Based Search Engine - lucene-java : Java Based Search Engine Full details are available at: http://vmgump.apache.org/gump/public/lucene-java/lucene-java/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [lucene-core-28072007.jar] identifier set to project name -DEBUG- Dependency on javacc exists, no need to add for property javacc.home. -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/lucene-java/lucene-java/gump_work/build_lucene-java_lucene-java.html Work Name: build_lucene-java_lucene-java (Type: Build) Work ended in a state of : Failed Elapsed: 39 secs Command Line: /usr/lib/jvm/java-1.5.0-sun/bin/java -Djava.awt.headless=true -Xbootclasspath/p:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dversion=28072007 -Djavacc.home=/srv/gump/packages/javacc-3.1 package [Working Directory: /srv/gump/public/workspace/lucene-java] CLASSPATH: /usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/lucene-java/build/classes/java:/srv/gump/public/workspace/lucene-java/build/classes/demo:/srv/gump/public/workspace/lucene-java/build/classes/test:/srv/gump/public/workspace/lucene-java/contrib/db/bdb/lib/db-4.3.29.jar:/srv/gump/public/workspace/lucene-java/contrib/gdata-server/lib/gdata-client-1.0.jar:/srv/gump/public/workspace/lucene-java/build/contrib/analyzers/classes/java:/srv/gump/public/workspace/lucene-java/build/contrib/ant/classes/java:/srv/gump/public/workspace/lucene-java/build/contrib/benchmark/classes/java:/srv/gump/public/workspace/lucene-java/build/contrib/db/bdb/classes/java:/srv/gump/public/workspace/lucene-java/build/contrib/db/bdb-je/classes/java:/srv/gump/public/workspace/lucene-java/build/contrib/gdata-server/classes/java:/srv/gump/public/workspace/lucene-java/build/contrib/highlighter/classes/java:/srv/gump/public/workspace/lucene-java/build/contrib/javascript/classes/java:/srv/gump/public/workspace/lucene-java/build/contrib/lucli/classes/java:/srv/gump/public/workspace/lucene-java/build/contrib/memory/classes/java:/srv/gump/public/workspace/lucene-java/build/contrib/queries/classes/java:/srv/gump/public/workspace/lucene-java/build/contrib/regex/classes/java:/srv/gump/public/workspace/lucene-java/build/contrib/similarity/classes/java:/srv/gump/public/workspace/lucene-java/build/contrib/snowball/classes/java:/srv/gump/public/workspace/lucene-java/build/contrib/spellchecker/classes/java:/srv/gump/public/workspace/lucene-java/build/contrib/surround/classes/java:/srv/gump/public/workspace/lucene-java/build/contrib/swing/classes/java:/srv/gump/public/workspace/lucene-java/build/contrib/wordnet/classes/java:/srv/gump/public/workspace/lucene-java/build/contrib/xml-query-parser/classes/java:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-trax.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/packages/junit3.8.1/junit.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/packages/je-1.7.1/lib/je.jar:/srv/gump/public/workspace/apache-commons/digester/dist/commons-digester.jar:/srv/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-28072007.jar:/srv/gump/packages/javacc-3.1/bin/lib/javacc.jar:/srv/gump/public/workspace/jline/target/jline-0.9.92-SNAPSHOT.jar:/srv/gump/packages/jtidy-04aug2000r7-dev/build/Tidy.jar:/srv/gump/public/workspace/junit/dist/junit-28072007.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-28072007.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-api-28072007.jar:/srv/gump/public/workspace/jakarta-servletapi-5/jsr154/dist/lib/servlet-api.jar:/srv/gump/packages/nekoh
Re: Last attempt
27 jul 2007 kl. 02.18 skrev Grant Ingersoll: or maybe there is a way to separate out the interface changes from the InstantiatedIndex stuff? One thing I came to think of is to use the IndexReader/IndexWriter "pipe" available in InstantiatedIndex. I.e. create a Directory, add documents via IndexWriter, and then pass a new IndexReader to InstantiatedIndex for merge. Even though this will slow things down when adding things to an index, I think this is an acceptable solution. That would only remove the IndexWriterInterface though. It would still require the definalization of Document, Term and IndexReader. And by removing IndexWriterInterface one somewhat cripples the NotifiableIndex. All in all I don't think it would count as gaining something. -- karl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (LUCENE-775) Searcher code creating Hits is somewhat messy
[ https://issues.apache.org/jira/browse/LUCENE-775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wettin closed LUCENE-775. -- Resolution: Won't Fix More nasty old code I'm getting ridth of. > Searcher code creating Hits is somewhat messy > - > > Key: LUCENE-775 > URL: https://issues.apache.org/jira/browse/LUCENE-775 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Karl Wettin >Priority: Trivial > Attachments: searcher.diff > > > This patch makes sure all Hits-resulting queries sent to Searcher pass though > the same methods, rather than an ad hoc Hits call per method call. Did it so > it would be easier for me to implement this decorated searcher cache of mine. > I could not find any implementations overriding the methods I set final, so I > think it is allright. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (LUCENE-534) CRUD facade on top of Lucene
[
https://issues.apache.org/jira/browse/LUCENE-534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin closed LUCENE-534.
--
Resolution: Won't Fix
This is an old ugly peice of code. Now gone.
> CRUD facade on top of Lucene
>
>
> Key: LUCENE-534
> URL: https://issues.apache.org/jira/browse/LUCENE-534
> Project: Lucene - Java
> Issue Type: New Feature
>Reporter: Karl Wettin
>Priority: Minor
> Attachments: se.snigel.lucene.crud.tar.gz,
> se.snigel.lucene.crud.tar.gz
>
>
> 29 mar 2006 kl. 15.43 Erik Hatcher wrote:
> Lazy loaded fields will be a nice addition to Lucene. I'm curious why the
> flag is set at indexing time rather than it being something that is
> controlled during retrieval somehow. I'm not sure what that API would look
> like, but it seems its a decision to be addressed during searching and
> reading of an index rather than during indexing itself.
> I reply:
> Lazy is nice. Thumbs up!
> But.
> I believe the field text persistency feature foolishly lead people to choose
> Lucene for persistency.
> I would prefer if we had identity safe Document and a CRUD pattern that bound
> them with an object instance. A standard implementation could act just as the
> current fields do.
> Perhaps this has already been discussed in the past.
> Perhaps I should settle with having a facade around Lucene rather than inside
> to save a few clock ticks.
> Perhaps everybody is not an OO-fundamentalist.
> Lucene to me is a set of tokens I can search to find my object instances
> already residing in memory. I use Prevayler for object persistency.
> As things I wrote required more indices I became sick keeping track of
> writers, searcher, readers, documents, et.c.. So I wrote a facade on top of
> Lucene that takes care of all the for me.
> It all comes down to four classes:
> final IndexHandler - one instance per Directory. Builds the index.
> CRUD - Create, Read, Update, Delete and searches.
> Tokenized - Any class that shoud be accessible from a Lucene
> search.
> Hit
> In the end, I do something like this:
> LinkedList> hits = getCRUD().search(new TermQuery(new
> Term("foo", "bar")), getIndexHandler().getSearcher());
> I have put it on the Jira in case anyone is interested. Made a small example.
> With some refactoring the pattern would support other implementations than
> Lucene.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
