Hibernate-reactive: Erreur de substitution de paramètre lors de la limitation des résultats sur MS SQL Server et Hibernate Reactive 1.0.0.CR9

Il y a quelque chose de bizarre dans ce SQL.

Pourquoi utilisons-nous même top n au lieu de offset ... fetch ... . Et pourquoi les parenthèses redondantes ?

Je suppose que Panache utilise setMaxResults() sur la requête.

Eh bien, cela devrait certainement être le cas. Panache n'a pas à faire sa propre génération SQL, n'est-ce pas @FroMage ?

Eh bien, j'ai essayé ceci en simple RH, et j'obtiens :

select hqlquerypa0_.id as id1_0_, hqlquerypa0_.description as descript2_0_, hqlquerypa0_.name as name3_0_, hqlquerypa0_.type as type4_0_ from Flour hqlquerypa0_ order by hqlquerypa0_.id offset <strong i="6">@P1</strong> rows fetch next <strong i="7">@P2</strong> rows only

Il me semble donc que ce doit être un problème lié à Panache.

Merci beaucoup pour votre évaluation et je vais contacter certains des projets de la pile. Étant donné que le seul HQL affiché dans les journaux de trace était FROM myproject.entities.Request WHERE requestor.firstName LIKE ?1 , j'ai supposé que l'ajout du top(?) provenait de l'implémentation MS SQL pour setMaxResults() , mais le SQL dans votre message montre qu'il utilise une syntaxe complètement différente.

Toujours confronté au problème, j'ai essayé d'ajouter une commande par, pour avoir ce HQL : FROM myproject.entities.Request WHERE requestor.firstName LIKE ?1 ORDER BY submitted

2021-08-05 16:20:37,992 DEBUG [org.hib.hql.int.ast.QueryTranslatorImpl] (vert.x-eventloop-thread-19) HQL: FROM myproject.entities.Request WHERE requestor.firstName LIKE ?1 ORDER BY submitted
2021-08-05 16:20:37,992 DEBUG [org.hib.hql.int.ast.QueryTranslatorImpl] (vert.x-eventloop-thread-19) SQL: select request0_.id as id1_1_, request0_.caseId as caseid2_1_, request0_.caseNumber as casenumb3_1_, request0_.expires as expires4_1_, request0_.addressLine1 as addressl5_1_, request0_.addressLine2 as addressl6_1_, request0_.agency as agency7_1_, request0_.city as city8_1_, request0_.email as email9_1_, request0_.firstName as firstna10_1_, request0_.lastName as lastnam11_1_, request0_.phone as phone12_1_, request0_.relationship as relatio13_1_, request0_.state as state14_1_, request0_.zipcode as zipcode15_1_, request0_.submitted as submitt16_1_ from Request request0_ where request0_.firstName like ? order by request0_.submitted

Cela a tenté d'exécuter le SQL suivant :

2021-08-05 16:20:38,022 DEBUG [org.hib.SQL] (vert.x-eventloop-thread-19)
    select
        request0_.id as id1_1_,
        request0_.caseId as caseid2_1_,
        request0_.caseNumber as casenumb3_1_,
        request0_.expires as expires4_1_,
        request0_.addressLine1 as addressl5_1_,
        request0_.addressLine2 as addressl6_1_,
        request0_.agency as agency7_1_,
        request0_.city as city8_1_,
        request0_.email as email9_1_,
        request0_.firstName as firstna10_1_,
        request0_.lastName as lastnam11_1_,
        request0_.phone as phone12_1_,
        request0_.relationship as relatio13_1_,
        request0_.state as state14_1_,
        request0_.zipcode as zipcode15_1_,
        request0_.submitted as submitt16_1_
    from
        Request request0_
    where
        request0_.firstName like <strong i="10">@P1</strong>
    order by
        request0_.submitted offset 0 rows fetch next ? rows only

Donc... le même problème existe toujours en ce sens qu'il n'a pas effectué correctement la substitution de paramètres (maintenant pour le fetch next ? rows only ), mais cela a modifié la syntaxe SQL générée pour correspondre à votre exemple.

Étant donné que Quarkus n'inclut pas encore hibernate-reactive-core 1.0.0.CR9, j'ai spécifiquement remplacé la version dans mon pom pour cela et hibernate-core 5.5.5.Final. Pourrais-je manquer une dépendance?

J'ai regardé où je pense que la requête Hibernate est créée dans Panache io.quarkus.hibernate.reactive.panache.common.runtime.CommonPanache QueryImpl:L254 , il semble n'utiliser que setFirstResult et setMaxResults sur la requête. J'ai regardé l'objet de requête dans le débogueur et à la fin de cette méthode createQuery , le ReactiveQueryImpl sous-jacent a queryOptions contenant firstRow=0 et maxRows=25.

Appréciez l'aide! (Comprenez que j'utilise un aperçu)

Je pense avoir trouvé un bogue, probablement dans SQLServerParameters.processLimit()

Panache crée une requête d'hibernation avec firstRow=0.

Dans org.hibernate.reactive.loader.ReactiveLoader.executeReactiveQueryStatement , SQLServer2012LimitHandler.getOffsetFetch() est appelé :

if ( !LimitHelper.hasFirstRow( selection ) ) {
    return " offset 0 rows fetch next ? rows only";
}
return " offset ? rows fetch next ? rows only";

Par conséquent, le SQL à ce stade se termine par offset 0 rows fetch next ? rows only . Notez le 0 au lieu du ?.
À partir de SQLServerParameters.processLimit() :

        if (isProcessingNotRequired(sql)) {
            return sql;
        }

        // Replace 'offset ? fetch next ? rows only' with the <strong i="17">@P</strong> style parameters for Sql Server
        int index = hasOffset ? parameterArray.length - 1 : parameterArray.length;
        int pos = sql.indexOf( " offset ?" );
        if ( pos > -1 ) {
            String sqlProcessed = sql.substring( 0, pos ) + " offset @P" + index++ + " rows";
            if ( sql.indexOf( " fetch next ?" ) > -1 ) {
                sqlProcessed += " fetch next @P" + index + " rows only ";
            }
            return sqlProcessed;
        }

        return sql;

Le sql.indexOf( " offset ?") est le problème : comme le LimitHandler a déjà codé en dur le décalage à 0, la sous-chaîne offset ? n'est pas trouvée, il n'essaie donc pas de traiter d'autres paramètres.
La chaîne de caractères imbriquée à la recherche de fetch next ? être déplacée en dehors de la correspondance pour offset ?

@bharward Si vous pouviez créer un

Je suppose que nous en examinerons également un qui utilise Panache, mais ce référentiel n'est pas le bon endroit pour ce genre de problème

Je soupçonne qu'il nous manque un test qui définit uniquement les résultats maximum et non le premier résultat.

Nous en avons un de base : https://github.com/hibernate/hibernate-reactive/blob/ccaa6061fc7e649ee0e1e09b5adda230d39dfe4f/hibernate-reactive-core/src/test/java/org/hibernate/reactive/HQLQueryParameterNamedLimitL54Test.java/org/hibernate/reactive/HQLQueryParameterNamedLimitL54Test.

@gavinking et @DavideD - Merci. Il semble qu'un autre test, qui ferait _both_ setFirstResult(0) et setMaxResults(n) (n étant n'importe quelle valeur > 0), reproduirait l'erreur que je vois.

SQLServer2012LimitHandler.getOffsetFetch() crée un code SQL différent lorsque firstResult==0 ("offset 0 rows...") par rapport à lorsque firstResult >0 ("offset ? rows");

Si cela pouvait toujours être utile, dans quelques jours, je pourrais passer du temps à créer un petit exemple uniquement pour les RH à reproduire ou à modifier HQLQueryParameterNamedLimitTest pour ajouter un test comme je l'ai décrit.

Ah, tu as raison, ce test échouera dans HQLQueryParameterNamedLimitTest :

    <strong i="7">@Test</strong>
    public void testFirstResultZeroAndMaxResults(TestContext context) {
        test(
                context,
                openSession()
                        .thenCompose( s ->
                                s.createQuery( "from Flour order by id" )
                                        .setFirstResult( 0 )
                                        .setMaxResults( 10 )
                                        .getResultList()
                                        .thenAccept( result -> {
                                            context.assertEquals( 3, result.size() );
                                        } )
                        )
        );
    }

J'irais regarder

@DavideD _en

       <strong i="7">@Test</strong>
    public void testFirstResultZeroAndMaxResultsWithoutOrderBy(TestContext context) {
        test(
                context,
                openSession()
                        .thenCompose( s ->
                                s.createQuery( "from Flour" )
                                        .setFirstResult( 0 )
                                        .setMaxResults( 10 )
                                        .getResultList()
                                        .thenAccept( result -> {
                                            context.assertEquals( 3, result.size() );
                                        } )
                        )
        );
    }

La différence réside dans la suppression du « ordre par ». La raison en est que SQLServer2005LimitHandler écrit la requête sous la forme select top(?) ... chaque fois que la requête n'inclut pas de "classement par", mais lorsqu'elle le fait, elle utilise la syntaxe offset ? fetch next ? . Je pense donc que 2 cas de test sont nécessaires.

Très appréciée!!