Well I could argue about "seconds" being appropriate for a database
report / batch work,
while a fulltext query would likely use milliseconds more appropriately,
but I value consistency way more than appropriateness as long as we
can choose for milliseconds.
+1
2010/12/8 Emmanuel Bernard <emmanuel(a)hibernate.org>:
On 8 déc. 2010, at 12:26, Sanne Grinovero wrote:
> I have no strong opinions on this;
> I like both
>
> setTimeout(long timeout, TimeUnit timeUnit, boolean allowPartialResults)
> and
> limitExecutionTimeTo (or boundExecutionTimeTo)
>
> The latter is only taken a milliseconds/long or is it also having a
> TimeUnit parameter
>
> but neither express clearly what's happening to my results.
>
> limitResultCollectionTimeTo( milliseconds ) ?
>
> (imho we can avoid the TimeUnit)
The timeUnit is to mimic the extended setTimeout method that takes a time unit. The
original Hibernate/JPA setTimeout uses second as the unit :(
/**
* *Experimental* API, subject to change or removal
*
* Limit the time used by Hibernate Search to execute the query. When the limit is
reached, results already
* fetched are returned. This time limit is a best effort. The query will likely
run for longer than the
* provided time.
*
* The time limit only applies to the interactions between Hibernate Search and
Lucene. In other words,
* a query to the database will not be limited.
*
* If the limit is reached and all results are not yet fetched, {@link
#hasPartialResults()} returns true.
*
* @param timeout time out period
* @param timeUnit time out unit
*/
FullTextQuery limitFetchingTime(long timeout, TimeUnit timeUnit);