hibernate - example - jpa ejemplos

org.hibernate.hql.ast.QueryTranslatorImpl list ATENCIÓN: firstResult/maxResults especificado con obtención de recopilación; aplicando en la memoria

Question

Estoy enfrentando un problema, tengo una consulta en JPA. como tengo algunas colecciones, necesito usar la búsqueda de unión izquierda o la búsqueda de unión interna

Mi problema es usar setFirstResult y setMaxResult para traer de vuelta un número preciso de resultados. cada vez que veo el resultado completo, vuelvo y solo DESPUÉS de que se use maxResult.

¿Hay alguna forma de hacer el maxResult antes?

Muchas gracias !

aquí hay más información:

mi problema es cuando uso eso:

startIndex = 0;
maxResults = 10;
query.setFirstResult(startIndex);
query.setMaxResults(maxResults);

Veo este mensaje en mi registro:

7 juin 2011 09:52:37 org.hibernate.hql.ast.QueryTranslatorImpl list ATENCIÓN: firstResult / maxResults especificado con la recuperación de recopilación; aplicando en la memoria!

Veo el resultado de 200 volver (en el registro) y después en el HashSet tengo finalmente los 10 resultados que pido.

su parece en la memoria es devolver el resultado de 200 y después de que se aplique maxResults en la memoria.

Estoy buscando si hay alguna manera de poder buscar y limitar el número de resultados.

Utilicé una solución alternativa, realicé una primera consulta para solicitar el ID de mi pedido, sin ninguna búsqueda, utilicé el maxResult. todo funciona perfectamente, se usa la instrucción límite. Después de usar mi consulta "grande" con la búsqueda y limitar el resultado dentro de la lista de identificación traer de vuelta en la primera.

aquí está mi consulta completa sin mi solución alternativa (observe que no hay límite generado como conversación por @Bozho):

select o from Order  o
   left join fetch o.notes note
   left join fetch o.orderedBy orderedBy
   left join fetch orderedBy.address addressOrdered 
   left join fetch orderedBy.language orderedByLg 
   left join fetch orderedByLg.translations orderedByLgTtrad
   left join fetch o.deliveredTo deliveredTo 
   left join fetch deliveredTo.address addressDelivered 
   left join fetch deliveredTo.language deliveredToLg
   left join fetch deliveredToLg.translations 
   left join fetch o.finalReceiptPlace finalReceiptPlace
   left join fetch finalReceiptPlace.address addressFinalReceiptPlace 
   left join fetch finalReceiptPlace.language finalReceiptPlaceLg 
   left join fetch finalReceiptPlaceLg.translations
   inner join fetch o.deliveryRoute delivery
   left join fetch delivery.translations
   inner join fetch o.type orderType
   left join fetch orderType.translations 
   inner join fetch o.currency currency
   left join fetch currency.translations
   left join fetch o.attachments 
   left join fetch note.origin orig
   left join fetch orig.translations
   left join fetch o.supplier sup  
   left join fetch sup.department dep 
   left join fetch o.stateDetail stateD
   inner join fetch stateD.state stat  
where 1=1 and o.entryDate >= :startDat

Answer 1

setMaxResult (10) ajusta la consulta con otro resultado limitante, por ejemplo, para el oráculo:
seleccione * de ("su consulta aquí") donde rownum <10

Descubrí esto hoy durante la investigación de la consulta que tomó 64 segundos, ahora, lleva 1 segundo.

... lo mismo para criteria.setProjection (Projections.rowCount ()). setMaxResults (10)

Answer 2

Depende del motor DB usado ...

Tengo el mismo problema con Derby DB setFirstResult / setMaxResults no se utilizan.

ROW_NUMBER() OVER()... parece ser la solución.

Desafortunadamente, no encuentro cómo puedo generar tales solicitudes con JPA sin especificar toda la solicitud en SQL.

Answer 3

Para entender por qué Hibernate hace esto, necesita comprender cómo Hibernate hace el ORM (mapeo relacional de objetos) involucrado para las entidades JPA.

Considere un conjunto simplificado de Entidades para su pedido. Class Order contiene 2 campos: number y customerId y una lista de líneas de pedido. Class OrderLine contiene los campos productCode y quantity , así como una clave de uid y una referencia al pedido principal.

Estas clases se pueden definir así:

@Entity
@Table(name = "ORDER")
public class Order {
    @ID
    @Column(name = "NUMBER")
    private Integer number;
    @Column(name = "CUSTOMER_ID")
    private Integer customerId;
    @OneToMany(mappedBy = "order", fetch = FetchType.LAZY)
    @OrderBy
    private List<OrderLine> orderLineList;

    .... // Rest of the class
}

@Entity
@Table(name = "ORDER_LINE")
public class OrderLine
{
    @ID
    @Column(name = "UID")
    private Integer uid;
    @Column(name = "PRODUCT_CODE")
    private Integer productCode;
    @Column(name = "QUANTITY")
    private Integer quantity;
    @Column(name = "ORDER_NUMBER")
    private Integer orderNumber;
    @ManyToOne(fetch = FetchType.LAZY, optional = false)
    @JoinColumn(name = "ORDER_NUMBER", referencedColumnName = "NUMBER", insertable = false, updatable = false)
    private Order order;

    .... // Rest of the class
}

Ahora, si realizó la siguiente consulta JPQL en estas Entidades:

SELECT o FROM Order o LEFT JOIN FETCH o.orderLineList

luego Hibernate realiza esta consulta como una consulta SQL ''aplanada'' similar a la siguiente:

SELECT o.number, o.customer_id, ol.uid, ol.product_code, ol.quantity, ol.order_number
FROM order o LEFT JOIN order_line ol ON order_line.order_number = order.number

que daría un resultado como este:

| o.number | o.customer_id | ol.uid | ol.product_code | ol.quantity |
|==========|===============|========|=================|=============|
| 1        | 123           | 1      | 1111            | 5           |
| 1        | 123           | 2      | 1112            | 6           |
| 1        | 123           | 3      | 1113            | 1           |
| 2        | 123           | 4      | 1111            | 2           |
| 2        | 123           | 5      | 1112            | 7           |
| 3        | 123           | 6      | 1111            | 6           |
| 3        | 123           | 7      | 1112            | 5           |
| 3        | 123           | 8      | 1113            | 3           |
| 3        | 123           | 9      | 1114            | 2           |
| 3        | 123           | 10     | 1115            | 9           |
...etc

que Hibernate usaría para "reconstruir" objetos Order con listas adjuntas de sub-objetos OrderLine .

Sin embargo, dado que el número de líneas de pedido por pedido es aleatorio, no hay forma de que Hibernate sepa cuántas filas de esta consulta se deben realizar para obtener el número máximo especificado de objetos Order . Por lo tanto, tiene que tomar toda la consulta y crear los objetos en la memoria hasta que tenga la cantidad correcta, antes de descartar el resto del conjunto de resultados. La advertencia de registro que produce alude a esto:

ATTENTION: firstResult/maxResults specified with collection fetch; applying in memory!

Recién ahora estamos descubriendo que estas consultas pueden tener un impacto significativo en el uso de la memoria del servidor, y hemos tenido problemas con nuestro servidor que se cae con errores de falta de memoria cuando se intentan estas consultas.

Por cierto, diré ahora que esto es mayormente teoría de mi parte y no tengo idea de cómo funciona el código real de Hibernate. La mayor parte de esto se puede obtener de los registros cuando Hibernate registra las declaraciones SQL que genera.

ACTUALIZACIÓN: Recientemente he descubierto un poco de ''gotcha'' con lo anterior.

Considere una tercera entidad llamada Shipment que es para una o más líneas de una orden.

La entidad de Shipment tendría una asociación @ManyToOne con la entidad Order .

Supongamos que tiene 2 envíos para la misma orden que tiene 4 líneas.

Si realiza una consulta JPQL para lo siguiente:

SELECT s FROM Shipment s LEFT JOIN s.order o LEFT JOIN FETCH o.orderLineList

Esperaría (o al menos yo lo hice) recuperar dos objetos de envío, cada uno con una referencia al mismo objeto Order, que a su vez contendría las 4 líneas.

¡No, mal otra vez! De hecho, obtienes 2 objetos de envío, cada uno refiriéndose al mismo objeto Order, que contiene 8 líneas. Sí, las líneas se duplican en el pedido. Y sí, incluso si especifica la cláusula DISTINCT.

Si investigas este tema aquí en SO o en otro lugar (más notablemente en los foros de Hibernate), encontrarás que esto es realmente una característica, no un error, de acuerdo con los poderes de Hibernate. ¡Algunas personas realmente quieren este comportamiento!

Imagínate.