[hibernate-dev] [HSEARCH] Proposal to change the default value of Field#norms()

[Andrej Golovnin]

Hi Hardy,

> It depends. Maybe you want to boost any of these fields ad index time.

OK, what about the document id? It is indexed with NOT_ANALYZED_NO_NORMS.
As far as I understand (please correct me if I'm wrong) to boost fields at index time
norms must be enabled for those fields. And because Hibernate Search uses for document ids
NOT_ANALYZED_NO_NORMS, adding @Boost to a document id would have no effect.
Although I'm not sure, someone really needs this. But it should be at least documented.

Also it is also not clear from the Hibernate Search documentation, what will happen
if I have following annotation on a field:

@Field(boost=@Boost(1.2f), norms = Norms.NO)
private String description;

Would I see a warning or maybe an error message from Hibernate Search?
Does make such combination sense?

>From http://www.lucidimagination.com/content/scaling-lucene-and-solr#d0e71
norms may not be useful for short or non full text fields. I personally consider
Enums, boolean/int/short, date, OIDs as short and non full text fields.
And in my application those fields are majority. We have 130 indexes.
Some of this indexes are shared by multiple entities. So I would guess
that we have ca. 140-150 indexed entities +  a lot of IndexEmbedded.
Of course I could do search&replace. But at some point a developer would
forget to add "norms = Norms.NO" to a field and our application would start
consuming more memory. And this is my dilemma. May be I can add an
automatic test to our build process which would force developers to add
"norms = Norms.NO". Alternative solution for would be to have a custom
Hibernate Search version, but I don't like this idea. I will discuss with my team
what is the best way to solve this small problem.

Btw Is it possible that OIDs added to index by IndexedEmbedded have
norms? Luke shows me it in two different indexes. Could someone
else please verify it? If it is the case, it would be nice if Hibernate Search
would have the same behavior for OIDs added to index either
by DocumentId or by IndexedEmbedded, e.g. index them with
NOT_ANALYZED_NO_NORMS.

I understand that for you as a framework provider it is difficult to find a golden path
which would satisfy every framework user. I think Sanne's suggestion
with "@Stereotype - like user annotations" may help us to achieve this goal.

Btw Hibernate Search and Hibernate helped us to create a really cool
product, so kudos to all who have contributed to this great projects!

Best regards,
Andrej Golovnin