lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Karl Wettin (JIRA)" <j...@apache.org>
Subject [jira] Updated: (LUCENE-534) CRUD facade on top of Lucene
Date Thu, 30 Mar 2006 01:55:34 GMT
     [ http://issues.apache.org/jira/browse/LUCENE-534?page=all ]

Karl Wettin updated LUCENE-534:
-------------------------------

    Attachment: se.snigel.lucene.crud.tar.gz

my CRUD pattern

> CRUD facade on top of Lucene
> ----------------------------
>
>          Key: LUCENE-534
>          URL: http://issues.apache.org/jira/browse/LUCENE-534
>      Project: Lucene - Java
>         Type: New Feature
>     Reporter: Karl Wettin
>     Priority: Minor
>  Attachments: 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<E extends Tokenized > - Create, Read, Update, Delete and searches.
> Tokenized<E id class> - Any class that shoud be accessible from a Lucene search.
> Hit<E extends Tokenized>
> In the end, I do something like this:
> LinkedList<Hit<MyClass>> 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.
-
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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message