Hi everyone,<br><br>I am working on batch indexing for Hibernate Search, I would like to define a new annotation<br>to set the needed "hints" for the process "@BatchIndexingHints"; one of the hint parameters is "which HQL query should I use?"<br>
The query is optional and I can fallback to a simple scrolling criteria, also this query should<br>not affect the functionality, only a performance hint to define join fetch collections needed for indexing.<br><br>The options we found (speaking with Emmanuel) are 4:<br>
<br>1)don't ask for a query but for the name of a named query.<br>I don't like this one as the definition of a named query is too flexible, e.g. I know for sure the<br>"readonly=true" is preferable for my purpose. Also this query is going to be created only once per<br>
thread during an indexing process, so I don't foresee a considerable performance boost.<br>Additionally the name of the NamedQuery would be redundant as I would be the only user (probably).<br><br>2)define the HQL to load all entities in @BatchIndexingHints.<br>
<br>3)Let the user only define a list of Strings, naming the properties to be eagerly loaded;<br>I would add these using .setFetchMode("prop1", FetchMode.EAGER) on the base Criteria.<br>This would be nice as we could be sure the users can't add some restriction or load<br>
the wrong entity, making it more safe.<br>But I wonder if we are loosing too much flexibility in this case.<br><br>4)don't tell anything at class level put add a boolean to desired fields, something like<br>@Field(eagerInBatch=true) or @Field(InBatch=FetchType.EAGER)<br>
(adding a property to existing annotation)<br><br>Besides the eagerly loading query the other parameters are 3 ints needed to set the size<br>of 3 different ThreadPools which do the job at different stages; they are here to provide<br>
a nice per-entity default, but if I move them to a configuration property and we<br>select option 4) I could avoid the new annotation.<br><br>some comments?<br><br>Sanne<br>