If you can find better name for the API, please advise. I am not happy with the current version Query luceneQuery = ...; FullTextQuery query = fullTextSession.createFullTextQuery(luceneQuery, User.class); //define the timeout in seconds query.limitFetchingTime(500, TimeUnit.MILLISECONDS); List results = query.list(); if ( query.hasPartialResults() ) {    displayWarningToUser(); } Emmanuel _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Solr uses 'timeAllowed' to provide the same functionality, it's think it's a nice name! On 6 Nov 2010 11:33, "Sanne Grinovero" <sanne.grinovero(a)gmail.com&gt; wrote: > Hello, > about naming I have no better ideas: > .limitFetchTime() //slightly different, not very happy about it either > > about API, does it really make sense to have hasPartialResults() as a > method of the Query? > It should be a List property I think - I have no strong opinions about > this as I don't like having to extend the List implementation. > > But really Query is something I might want to reuse - unlikely but I'd > expect that to work fine. > So what about: > > SomeNewList results = query.list(500, TimeUnit.MILLISECONDS) > or a batter named method. > > So: > > if ( results.hasPartialResults() ) { > displayWarningToUser(); > } > > This is one of those cases in which I miss the option of having a > couple of values from a function. > > Sanne > > 2010/11/5 Emmanuel Bernard <emmanuel(a)hibernate.org&gt;: >> If you can find better name for the API, please advise. I am not happy with the current version >> >> Query luceneQuery = ...; >> FullTextQuery query = fullTextSession.createFullTextQuery(luceneQuery, User.class); >> >> //define the timeout in seconds >> query.limitFetchingTime(500, TimeUnit.MILLISECONDS); >> List results = query.list(); >> >> if ( query.hasPartialResults() ) { >> displayWarningToUser(); >> } >> >> Emmanuel >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev

On Wed, 08 Dec 2010 11:40:57 +0100, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: > limitExecutionTimeTo (or boundExecutionTimeTo) seems exactly what we are > looking for. > > WDYT? I find it a little confusing to have setTimeout and limitFetchingTime (or be it limitExecutionTimeTo). Why not having another version of setTimeout - setTimeout(long timeout, TimeUnit timeUnit, boolean allowPartialResults)? --Hardy _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

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);

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 <emmanuel(a)hibernate.org&gt;: >> >> 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);

Hello, about naming I have no better ideas: .limitFetchTime() //slightly different, not very happy about it either about API, does it really make sense to have hasPartialResults() as a method of the Query? It should be a List property I think - I have no strong opinions about this as I don't like having to extend the List implementation. But really Query is something I might want to reuse - unlikely but I'd expect that to work fine. So what about: SomeNewList results = query.list(500, TimeUnit.MILLISECONDS) or a batter named method. So: if ( results.hasPartialResults() ) { displayWarningToUser(); } This is one of those cases in which I miss the option of having a couple of values from a function. Sanne 2010/11/5 Emmanuel Bernard <emmanuel(a)hibernate.org&gt;: > If you can find better name for the API, please advise. I am not happy with the current version > > Query luceneQuery = ...; > FullTextQuery query = fullTextSession.createFullTextQuery(luceneQuery, User.class); > > //define the timeout in seconds > query.limitFetchingTime(500, TimeUnit.MILLISECONDS); > List results = query.list(); > > if ( query.hasPartialResults() ) { > displayWarningToUser(); > } > > Emmanuel > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev >

The other option I've been thinking about is to get limitFetchTime() / limitTimeAllowedTo() to return a Future object or some equivalent notion say a BooleanHolder. BooleanHolder hasPartialResults = query.limitTimeAllowedTo(500, MILLISECONDS, hasPartialResults); query.list(); if ( hasPartialResults.get() ) {  //do stuffs } But:  - that's a bit weird to get a future in this sync API  - it breaks the method chaining used in the rest of the API Another possibility is to optionally let people pass the boolean holder that is populated after the call BooleanHolder hasPartialResults = new BooleanHolder(); List results = query.limitTimeAllowedTo(500, MILLISECONDS, hasPartialResults).list(); if ( hasPartialResults.get() ) {  //do stuffs } WDYT? On 6 nov. 2010, at 15:25, Emmanuel Bernard wrote: > You'll need to extend: > - List > - Iterator > - ScrollableResults > > Not sure that's a good thing. > > You can reuse the query as long as you check hasPartialResults() before calling list/iterate/scroll query again. > > PS: we should add tests about query reusability, I'm not sure it works as expected today. > > > On 6 nov. 2010, at 12:31, Sanne Grinovero wrote: > >> Hello, >> about naming I have no better ideas: >> .limitFetchTime() //slightly different, not very happy about it either >> >> about API, does it really make sense to have hasPartialResults() as a >> method of the Query? >> It should be a List property I think - I have no strong opinions about >> this as I don't like having to extend the List implementation. >> >> But really Query is something I might want to reuse - unlikely but I'd >> expect that to work fine. >> So what about: >> >> SomeNewList results = query.list(500, TimeUnit.MILLISECONDS) >> or a batter named method. >> >> So: >> >> if ( results.hasPartialResults() ) { >>   displayWarningToUser(); >> } >> >> This is one of those cases in which I miss the option of having a >> couple of values from a function. >> >> Sanne >> >> 2010/11/5 Emmanuel Bernard <emmanuel(a)hibernate.org&gt;: >>> If you can find better name for the API, please advise. I am not happy with the current version >>> >>> Query luceneQuery = ...; >>> FullTextQuery query = fullTextSession.createFullTextQuery(luceneQuery, User.class); >>> >>> //define the timeout in seconds >>> query.limitFetchingTime(500, TimeUnit.MILLISECONDS); >>> List results = query.list(); >>> >>> if ( query.hasPartialResults() ) { >>>   displayWarningToUser(); >>> } >>> >>> Emmanuel >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev

there's a similar case already: query.getResultSize() //relates to the last returned list and so looking at the complexity of proposed alternatives, I'm not strongly against your original suggestion to provide a method on the query object. Alternatively we might consider there might be enough good reasons to create a new object to collect information about the executed query. query.getLastQueryExecutionMetadata(). .hasPartialResults() .executionTime() //possibly interesting .getResultSize() I would be fine too in considering the Query object the right place for this info (as it currently is) documenting that these methods refer to the last execution. Sanne 2010/11/6 Emmanuel Bernard <emmanuel(a)hibernate.org&gt;: > The other option I've been thinking about is to get limitFetchTime() / limitTimeAllowedTo() to return a Future object or some equivalent notion say a BooleanHolder. > > BooleanHolder hasPartialResults = query.limitTimeAllowedTo(500, MILLISECONDS, hasPartialResults); > query.list(); > if ( hasPartialResults.get() ) { > //do stuffs > } > > But: > - that's a bit weird to get a future in this sync API > - it breaks the method chaining used in the rest of the API > > Another possibility is to optionally let people pass the boolean holder that is populated after the call > > BooleanHolder hasPartialResults = new BooleanHolder(); > List results = query.limitTimeAllowedTo(500, MILLISECONDS, hasPartialResults).list(); > if ( hasPartialResults.get() ) { > //do stuffs > } > > WDYT? > > On 6 nov. 2010, at 15:25, Emmanuel Bernard wrote: > >> You'll need to extend: >> - List >> - Iterator >> - ScrollableResults >> >> Not sure that's a good thing. >> >> You can reuse the query as long as you check hasPartialResults() before calling list/iterate/scroll query again. >> >> PS: we should add tests about query reusability, I'm not sure it works as expected today. >> >> >> On 6 nov. 2010, at 12:31, Sanne Grinovero wrote: >> >>> Hello, >>> about naming I have no better ideas: >>> .limitFetchTime() //slightly different, not very happy about it either >>> >>> about API, does it really make sense to have hasPartialResults() as a >>> method of the Query? >>> It should be a List property I think - I have no strong opinions about >>> this as I don't like having to extend the List implementation. >>> >>> But really Query is something I might want to reuse - unlikely but I'd >>> expect that to work fine. >>> So what about: >>> >>> SomeNewList results = query.list(500, TimeUnit.MILLISECONDS) >>> or a batter named method. >>> >>> So: >>> >>> if ( results.hasPartialResults() ) { >>> displayWarningToUser(); >>> } >>> >>> This is one of those cases in which I miss the option of having a >>> couple of values from a function. >>> >>> Sanne >>> >>> 2010/11/5 Emmanuel Bernard <emmanuel(a)hibernate.org&gt;: >>>> If you can find better name for the API, please advise. I am not happy with the current version >>>> >>>> Query luceneQuery = ...; >>>> FullTextQuery query = fullTextSession.createFullTextQuery(luceneQuery, User.class); >>>> >>>> //define the timeout in seconds >>>> query.limitFetchingTime(500, TimeUnit.MILLISECONDS); >>>> List results = query.list(); >>>> >>>> if ( query.hasPartialResults() ) { >>>> displayWarningToUser(); >>>> } >>>> >>>> Emmanuel >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >> >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev