Discussion :

[v4np13]

Bonjour,

Je suis en train de réfactorer une vieille application de recherche de documents. Pour cela, j'ai repris les fichiers hbm inutilisés jusqu'à présent, la DB qui ne peut pas être modifiée et j'ai décidé d'utiliser l'API criteria.

La recherche de documents se base sur plusieurs champs stockés dans plusieurs tables de la DB. Pour éviter d'avoir une grosse méthode contenant toute la requête, j'ai découpé cela en utilisant le pattern composite et chaque paramètre de la recherche a une classe qui définit les jointures nécessaires, les restrictions à utiliser, les order by,...

Cela fonctionne bien sauf pour trier par date l'ensemble des documents par date. Ce tri se fait sur un champs d'une table qui nécessite de deux jointures:

Document 1 -> * Revision 1 -> * Revision-language.date

Ma query actuelle ressemble à ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
 
select
        this_.ID as ID23_3_,
        this_.STUDY_NUMBER as STUDY2_23_3_,
        this_.PUBLICATION_TYPE as PUBLICAT3_23_3_,
        this_.EXECUTIVE_SUMMARY as EXECUTIVE5_23_3_,
        this_.AUTHOR as AUTHOR23_3_,
        this_.SUPPLIED_BY as SUPPLIED7_23_3_,
        this_.EDITOR_ID as EDITOR8_23_3_,
        this_.LAST_PUBLICATION_DATE as LAST10_23_3_,
        this_.DATE_MODIFICATION as DATE12_23_3_,
        this_.DATE_INSERTION as DATE13_23_3_,
        this_.USER_MODIFICATION as USER14_23_3_,
        this_.USER_INSERTION as USER15_23_3_,
        this_.OFF_LINE as OFF16_23_3_,
        revisions1_.ID as ID21_0_,
        revisions1_.STUDY_ID as STUDY2_21_0_,
        revisions1_.REVISION_NUMBER as REVISION3_21_0_,
        revisionla2_.ID as ID22_1_,
        revisionla2_.REVISION_ID as REVISION2_22_1_,
        revisionla2_.REVISION_NUMBER as REVISION3_22_1_,
        revisionla2_.LANGUAGE as LANGUAGE22_1_,
        revisionla2_.SOURCE_LANGUAGE as SOURCE5_22_1_,
        revisionla2_.PUBLICATION_DATE as PUBLICAT6_22_1_,
        revisionla2_.TITLE as TITLE22_1_,
        revisionla2_.ABSTRACT_SUMMARY as ABSTRACT9_22_1_,
        revisionla2_.NOTE as NOTE22_1_,
        revisionla2_.NUMBER_OF_PAGES as NUMBER11_22_1_,
        revisionla2_.ISBN_NUMBER as ISBN12_22_1_,
        revisionla2_.FORCE_ARCHIVE as FORCE13_22_1_,
        revisionla2_.DIFFUSION as DIFFUSION22_1_,
        estthemes7_.STU_STUDY_ID as STU1_,
        themes3_.ID as STU2_,
        themes3_.ID as ID25_2_,
        themes3_.CODE as CODE25_2_,
    from
        EST_STUDY this_
    inner join
        EST_REVISION revisions1_
            on this_.ID=revisions1_.STUDY_ID
    inner join
        EST_REVISION_LANGUAGE revisionla2_
            on revisions1_.ID=revisionla2_.REVISION_ID
    inner join
        EST_STUDY_THEME estthemes7_
            on this_.ID=estthemes7_.STU_STUDY_ID
    inner join
        EST_THEME themes3_
            on estthemes7_.STU_THEME_ID=themes3_.ID
    where
        (
            this_.ID=?
            or this_.ID=?
            or this_.ID=?
            or this_.ID=?
            or this_.ID=?
            or this_.ID=?
            or this_.ID=?
            or this_.ID=?
            or this_.ID=?
            or this_.ID=?
            or lower(revisionla2_.TITLE) like ?
            or lower(revisionla2_.ABSTRACT_SUMMARY) like ?
        )
        and (
            this_.OFF_LINE=?
            or this_.OFF_LINE is null
        )
    order by
        revisionla2_.PUBLICATION_DATE desc

Le résultat de la recherche est correct sauf ce qui concerne le tri par date. Pour l'instant, c'est plus ou moins bien trier. J'ai des dates 2011, 2010, de nouveau 2011, 2009,...

Auriez-vous une/des idées pour corriger cela ?

Merci d'avance,

[v4np13]

J'ai l'impression que cela vient d'un mauvais mapping de mes champs date.

J'utilise Hibernate avec une DB Oracle 10G.

Quand j'exécute la query générée par Hibernate en DB sans passer par Hibernate, j'ai le bon résultat, bien trié. Par contre avec Hibernate, il s'emmèle les pinceaux.

Voici comme j'ai essayé de mapper ma date :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
<property name="publicationDate" column="PUBLICATION_DATE" type="timestamp" />
 
<property name="publicationDate" column="PUBLICATION_DATE" type="date" />
 
<property name="publicationDate" column="PUBLICATION_DATE" />

Et dans ma classe, j'utilise java.util.Date.

Connaitriez-vous problème ?

Merci d'avance

[Rei Ichido]

Il ne me semble pas que l'API Criteria effectue de tri après le SQL ... Donc si le SQL généré renvoie le bon ordre, la liste sera elle aussi bien ordonnée.
Deux idées :
1. Tu passes ensuite par une autre structure, et du coup l'ordre est perdu (par exemple, un set).
2. Tu n'affiches pas la bonne date dans ton IHM

Tu pourrais fournir un brin de code, si aucune de ces deux suggestions ne se révèle concluante ?

[v4np13]

Je passe par un Set car je ne peux pas utiliser les outils de pagination d'Hibernate avec ma query.

Quand je fais l'order by sur un champs d'une autre table et que je veux éviter les doublons avec la ligne suivante il plante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

executableCriteria.setResultTransformer(Criteria.DISTINCT_ROOT_ENTITY);

Donc j'avais trouvé comme solution ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
start = start == -1 ? 0 : start;
if (lenght == -1) {
	lenght = Integer.MAX_VALUE;
}
 
int nbElements = 0;
int position = 0;
Set ignoredObjects = new HashSet();
while (scrollResults.next() && nbElements < lenght) {
	session.clear();
	if (start > position) {
		if (ignoredObjects.add(scrollResults.get(0))) {
			position++;
		}
	} else if (results.add(scrollResults.get(0))) {
		nbElements++;
	}
}
 
scrollResults.close();

Il faudrait utiliser un autre type de collection ?

EDIT: je suis en train d'essayer en utilisant des instances de LinkedHashSet

[Rei Ichido]

Un Set ne préserve par défaut aucun ordre (par exemple, un HashSet). Effectivement un LinkedHashSet permettra de garder l'ordre d'insertion, ce qui ensuite te permettra de faire une itération dessus en ayant le même ordre que celui qu'avait la liste ...

Par contre je suis étonné de ce que tu ne puisses pas utiliser DISTINCT_ROOT_ENTITY. Tu peux indiquer le code que tu avais essayé d'utiliser et l'exception obtenue ?

[v4np13]

J'avais cette exception:

ORA-01791
ORA-01791: not a SELECTed expression
Cause: There is an incorrect ORDER BY item. The query is a SELECT DISTINCT query with an ORDER BY clause. In this context, all ORDER BY items must be constants, SELECT list expressions, or expressions whose operands are constants or SELECT list expressions.
Action: Remove the inappropriate ORDER BY item from the SELECT list and retry the statement.

Cela venait de la combinaison entre DISTINCT_ROOT_ENTITY et l'order by avec la propriété venant d'une autre table.

Puis l'autre problème que j'avais avec DISTINCT_ROOT_ENTITY, si je mettais :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
if (start != -1) {
	executableCriteria.setFirstResult(start);
 }
 if (lenght != -1) {
	 executableCriteria.setMaxResults(lenght);
	 executableCriteria.setFetchSize(lenght); // Performance issue
 }

Il me faisait d'abord le setMaxResult 10 par exemple, puis avec le DISTINCT_ROOT_ENTITY, il me retirait les doublons, donc au final j'avais moins de 10 entrées.

Cela m'embête un peu ces contournements, ça complexifie la lecture du code,...