i would like to have a single lucene field that has mutliple object properties indexed for easy searching accross multiple properties in tokenized way, but some of those fields also have to be indexed untokenized under the property name.

I would like to write something like this :

@Field(name="all", index=Index.TOKENIZED, store=Store.NO)
@Field(name="from", index=Index.UNTOKENIZED, store=Store.YES)
public String getFrom() { ... }

how can this be achieved?

hi,

how about this:

@Field(name="from", index=Index.UNTOKENIZED, store=Store.YES)
public String getFrom() { ... }

@Field(name="all", index=Index.TOKENIZED, store=Store.NO)
public String getAll(){
return getFrom();
}

hi true,

let me be more specific, the " all " property should contain the tokenized content of several propertie ( a single combined property to search on )

the below is working but it would still be much nicer to be able to annotate a single property twice (would be preferred to to artificial getters)

thax for the reaction

current solution :

@Field(name="from", index=Index.UNTOKENIZED, store=Store.YES)
public String getFrom() { ... }

@Field(name="all", index=Index.TOKENIZED, store=Store.NO)
public String getFromAll(){
return getFrom();

@Field(name="to", index=Index.UNTOKENIZED, store=Store.YES)
public String getFrom() { ... }

@Field(name="all", index=Index.TOKENIZED, store=Store.NO)
public String getToAll(){
return getFrom();

mh, maybe i dont get the point:

why do you even want to index a field twice? A tokenized field will just break up your text for that field and generate matches for every token in a query. And for the search accross multiple fields, there is the MultiFieldQueryParser which takes an array of fields to search in...

the reasons why is explained in

The All Field
You also ought to really think about glomming all of the Field data together and storing it as some sort of "all" Field. This is the easiest way to set it up so your users can search all Fields at once, if they want. Yes, you could come up with a complex scheme to rewrite your users' query so it searches across all of the known fields, but remember, keep it simple

from http://darksleep.com/lucene/

thank you for the reference to the multifieldqueryparser. i guess that in hibernate search context this could be more appropriate than building an 'ALL' field, however, in terms of query performance, i recall some statements that the 'all' field approach would be better.

@Fields will be introduced soon
But wrt your problem, I think "all" is a bad idea. It prevent you from boosting one field over another one (all of them considered equals). The MultifieldQueryParser is much more flexible and adjustable per usecase.

As for query perfs, fast enough is what you should target