Web servers - CHAPTER 14 Querying with HQL and JPA QL
CHAPTER 14 Querying with HQL and JPA QL Query execution options that are based on the SQL result rows, such as pagination with setMaxResults()/setFirstResult(), are semantically incorrect if a collection is eagerly fetched. If you have an eager fetched collection in your query, at the time of writing, Hibernate falls back to limiting the result in-memory, instead of using SQL. This may be less efficient, so we don t recommend the use of JOIN FETCH with setMaxResults()/set- FirstResult(). Future versions of Hibernate may fall back to a different SQL query strategy (such as two queries and subselect fetching) if setMaxResults()/setFirstResult() is used in combination with a JOIN FETCH. This is how Hibernate implements dynamic association fetching, a powerful feature that is essential for achieving high performance in any application. As explained in chapter 13, section 13.2.5, Optimization step by step, tuning the fetch plan and fetching strategy with queries is your first optimization, followed by global settings in mapping metadata when it becomes obvious that more and more queries have equal requirements. The last join option on the list is the theta-style join. Theta-style joins A product lets you retrieve all possible combinations of instances of two or more classes. This query returns all ordered pairs of Users and Category objects: from User, Category Obviously, this isn t usually useful. There is one case where it s commonly used: theta-style joins. In traditional SQL, a theta-style join is a Cartesian product together with a join condition in the WHERE clause, which is applied on the product to restrict the result. In HQL and JPA QL, the theta-style syntax is useful when your join condition isn t a foreign key relationship mapped to a class association. For example, suppose you store the User s name in log records, instead of mapping an association from LogRecord to User. The classes don t know anything about each other, because they aren t associated. You can then find all the Users and their LogRecords with the following theta-style join: from User user, LogRecord log where user.username = log.username The join condition here is a comparison of username, present as an attribute in both classes. If both rows have the same username, they re joined (with an inner join) in the result. The query result consists of ordered pairs:
You need excellent and relaible webhost company to host your web applications? Then pay a visit to Inexpensive Web Hosting services.