You obviously haven't tried to build a unit test for this. HSQLDB + Lucene + 
HSearch are simply way too fast ;)

On 8 déc. 2010, at 14:01, Sanne Grinovero wrote:

> 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 <emman...@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);


_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Reply via email to