Christian Beikov ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *commented* on HHH-304 ( https://hibernate.atlassian.net/browse/HHH-304?atlOrigin=eyJpIjoiNzQwY2Q1... ) Re: Subselect fetching with setMaxResults() ( https://hibernate.atlassian.net/browse/HHH-304?atlOrigin=eyJpIjoiNzQwY2Q1... ) I’m not sure it’s a good idea to do this by default as this will only work safely if you use the SNAPSHOT or SERIALIZABLE transaction isolation level. With READ_COMMITTED, new rows might pop into existence between the first query and the subselect fetch (according to the order by clause) which will cause certain collections to be empty. Imagine the simplest case from Order o order by o.id desc limit 1. When orderItems is SUBSELECT fetched, but between the first and the second query a new order is committed, the subselect fetch query will return results that are not related to the originally fetched orders. Now, we could detect this scenario by checking if the result contains keys that have no correspondence and then execute another query, without order by and limit, to make sure we load all the data, but not sure if that is so great. Overall, I think we need to at least discuss the scenario before implementing this. Maybe introduce some config option, I know it sucks, which controls whether we want to ignore the possible READ_COMMITTED issue or not, and by default, handle it transparently in the way I described. ( https://hibernate.atlassian.net/browse/HHH-304#add-comment?atlOrigin=eyJp... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-304#add-comment?atlOrigin=eyJp... ) Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.... ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=Em... ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100206- sha1:1c596f6 )