But Lucene has its own QueryParser already, why would we write another syntax
and another parser? Yes, it is not very stable and throws exceptions all the
time (fun on JIRA which uses it). I see more chance improving the Lucene
criteria API though by abstracting it a little. For example:
| @org.hibernate.search.annotations.Indexed
| @Entity
| @Searchable(description = "Documents")
| public class Document {
|
| @org.hibernate.search.annotations.Field(index =
org.hibernate.search.annotations.Index.TOKENIZED)
| @Searchable(description = "Content")
| private String content;
|
| @org.hibernate.search.annotations.Field(
| index = org.hibernate.search.annotations.Index.UN_TOKENIZED,
| store = org.hibernate.search.annotations.Store.YES
| )
| @org.hibernate.search.annotations.DateBridge(resolution =
org.hibernate.search.annotations.Resolution.DAY)
| @Searchable(description = "Modified", type = SearchableType.PASTDATE)
| protected Date lastModifiedOn;
|
| }
|
The @Searchable annotation is mine. With this I can:
- build an internal metamodel of searchable entities and properties
- build a UI from this metamodel (I have the description text)
- generate a compound Lucene query with AND/OR semantics (depending on users
choice) from the UI input, using some generic value holders to transport the
search strings
I think this can be made generic enough to justify inclusion in Hibernate
Search and Seam (for the UI part).
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4075057#4075057
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4075057
_______________________________________________
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
