Problème de clé étrangère avec PostgreSQL

Version imprimable

Bonjour à tous !

j'ai une application web avec les technos suivantes : Spring 3 - JPA 2 - Hibernate 3.5.6.
Au début j'utilisais le SGBD MySQL, mais certains problèmes de gestion des transactions m'ont poussés à essayer avec un autre SGBD (problème en question abordé dans cet autre sujet).

J'ai donc installé PostgreSQL, changé la configuration JPA, et la magie des applis multicouches a opéré.
Mais une fois que j'ai enlevé le patch qui contournait le problème de transaction pour MySQL (des @Transactional(propagation=Propagation.NEVER) sur un certain nombre de méthodes), une erreur de clé étrangère est apparue.

J'en viens donc au problème à proprement parlé (désolée pour le message un peu long, mais je me dis toujours qu'il est plus facile de résoudre un problème quand on a son contexte :aie:) :
J'ai une entité Questionnaire et une entité Question. un Questionnaire contient plusieurs questions et une question ne se rapporte qu'à un seul questionnaire. Donc j'ai un champs idQuestionnaire dans mon entité Question qui est une clé étrangère vers le Questionnaire. Voici le mapping de ces deux entités :
Question :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
@Entity
public class Question extends DomainObject {
	private static final long serialVersionUID = 1L;
 
	@Id
	@GeneratedValue(strategy = GenerationType.AUTO)
	private Long idQuestion;
 
	private Integer numQuestion;
	private String question;
	private String typeReponse;
 
	@ManyToOne(fetch = FetchType.LAZY)
	@JoinColumn(name = "idQuestionnaire")
	private Questionnaire questionnaire;
//Constructeurs, getters and setters

Questionnaire :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
@Entity
public class Questionnaire extends DomainObject {
 
	private static final long serialVersionUID = 1L;
 
	@Id
	@GeneratedValue(strategy = GenerationType.AUTO)
	@Column(name = "idQuestionnaire", nullable = false)
	private Long idQuestionnaire;
 
	private String numero;
	private String titre;
	private Character sexeDestinataire;
	private Boolean publie;
 
	@OneToMany(mappedBy = "pk.questionnaire", cascade = {CascadeType.REMOVE}, fetch = FetchType.LAZY)
	private List<ListeQuestionnaire> listeQuestionnaires = new ArrayList<ListeQuestionnaire>();
 
	@OneToMany(mappedBy = "questionnaire", cascade={CascadeType.REMOVE}, fetch = FetchType.LAZY)
	private List<Question> listeQuestions = new ArrayList<Question>();
 
	@OneToMany(mappedBy = "questionnaire", cascade={CascadeType.REMOVE}, fetch = FetchType.LAZY)
	private List<Reponse> listeReponses = new ArrayList<Reponse>();
//Constructeurs, getters and setters

Mes tests du dao du Questionnaire passent sans problème, par contre les tests du dao des questions passent pas. Lors de la méthode d'initialisation des données :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
@Before
@Transactional
public void startTransaction() throws ParseException{
	Questionnaire q1 = new Questionnaire();
	q1.setNumero("Q1");
	q1.setTitre("Nutrition");
	q1.setSexeDestinataire('b');
	questionnaire = serviceQuestionnaire.saveOne(q1);
 
	Question question1 = new Question();
	question1.setNumQuestion(1);
	question1.setQuestion("question 1");
	question1.setTypeReponse("texte");
	question1.setQuestionnaire(questionnaire);
 
	question = questionDao.saveOne(question1);
}

la ligne question = questionDao.saveOne(question1); génère l'erreur suivante :

Code:

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
WARN  - JDBCExceptionReporter      - SQL Error: 0, SQLState: 23503
ERROR - JDBCExceptionReporter      - L'élément du batch 0 insert into Question (numQuestion, question, idQuestionnaire, typeReponse, idQuestion) values ('1', 'question 1', '1', 'texte', '2') a été annulé. Appeler getNextException pour en connaître la cause.
WARN  - JDBCExceptionReporter      - SQL Error: 0, SQLState: 23503
ERROR - JDBCExceptionReporter      - ERROR: insert or update on table "question" violates foreign key constraint "fkbe5ca00676039098"
  Détail*: Key (idquestionnaire)=(1) is not present in table "questionnaire".
ERROR - tractFlushingEventListener - Could not synchronize database state with session
org.hibernate.exception.ConstraintViolationException: Could not execute JDBC batch update
	at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:96)
	at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66)
	at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:275)
	at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:262)
	at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:178)
	at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:321)
	at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:51)
	at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1206)
	at org.hibernate.ejb.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:791)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.springframework.orm.jpa.ExtendedEntityManagerCreator$ExtendedEntityManagerInvocationHandler.invoke(ExtendedEntityManagerCreator.java:365)
	at $Proxy30.flush(Unknown Source)
	at fr.statlife.protoE4N.data.dao.jpa.AbstractDaoJPAImpl.saveOne(AbstractDaoJPAImpl.java:45)
	at fr.statlife.protoE4N.data.dao.jpa.TestQuestionDao.startTransaction(TestQuestionDao.java:54)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
	at org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.java:74)
	at org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(RunAfterTestMethodCallbacks.java:82)
	at org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(SpringRepeat.java:72)
	at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:240)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
	at org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
	at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:70)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
	at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:180)
	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:49)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: java.sql.BatchUpdateException: L'élément du batch 0 insert into Question (numQuestion, question, idQuestionnaire, typeReponse, idQuestion) values ('1', 'question 1', '1', 'texte', '2') a été annulé. Appeler getNextException pour en connaître la cause.
	at org.postgresql.jdbc2.AbstractJdbc2Statement$BatchResultHandler.handleError(AbstractJdbc2Statement.java:2598)
	at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1836)
	at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:407)
	at org.postgresql.jdbc2.AbstractJdbc2Statement.executeBatch(AbstractJdbc2Statement.java:2737)
	at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:70)
	at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:268)
	... 42 more

Alors j'ai bien lu l'erreur, il dit qu'il n'y a pas de questionnaire avec l'id 1, sauf que ce questionnaire a été créé et enregistré dans la base juste avant... Donc normalement, l'enregistrement devrait être dans la base.
Il est dans le contexte de persistance en tous cas car j'arrive à le récupérer et à l'afficher.
Alors pourquoi cette erreur?
J'ai trouvé sur le forum une autre discussion qui rapporte un problème similaire datant de 2006, mais cette discussion n'a jamais été résolue au final...

Merci d'avance pour toute l'aide que vous pourrez m'apporter :mrgreen:

petite précision : voici le code d'une méthode de test
Code:

1 2 3 4 5 6 7 8 9 @Test @Transactional//(propagation=Propagation.NEVER) @Rollback public void testFindAll() { List<Question> questionsAttendus = new ArrayList<Question>(); questionsAttendus.add(question); Assert.assertEquals(questionsAttendus, questionDao.findAll()); }
si je décommente le (propagation=Propagation.NEVER), le test passe et il n'y a plus cette erreur de clé étrangère. J'avais mis cet attribut pour éviter un lock sur mes tables MySQL qui bloquait l'application.
Si j'ai installé PostgreSQL c'est justement pour ne pas avoir à ajouter cet attribut...

12/07/2011, 09h24
zaboug

personne n'a de piste de recherche?
je manque cruellement d'expertise en la matière, y'a personne pour m'aider au boulot, et le problème est vraiment bloquant car si je continue sur d'autres trucs et que ça marche pas, y'a toujours un risque que le problème vienne directement de ce premier problème...

J'ai sans doute fait plusieurs petites erreurs (car une seule grosse serait sans doute plus évidente à trouver), mais où?
y'a-t-il des différences entre un mapping MySQL et un mapping PostgreSQL?
à moins que ça ne soit ma manière de tester qui pose problème?
je sais vraiment pas dans quelle direction chercher :(
13/07/2011, 08h38
bboulch

Bonjour,

Une piste éventuelle pourrait être de mettre la propriété show_sql à true dans hibernate afin de voir quelles sont les requêtes SQL générées et peut être comprendre ce qui ne va pas.

Si les requêtes ne sont pas très clair, tu peux aussi te retourner vers p6spy qui fournit le détail des instructions SQL exécutées.

Benoit

Bonjour Benoit,

merci de ta réponse.
En fait, la propriété show SQL était déjà à true. J'en ai pas parlé car y'a rien qui me choquait dans les requêtes SQL. Voici les traces plus complètes dans la console :

Code:

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
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
[...]
INFO  - SchemaExport               - schema export complete
INFO  - ionalTestExecutionListener - Began transaction (1): transaction manager [org.springframework.orm.jpa.JpaTransactionManager@679b2faf]; rollback [true]
 
Hibernate: 
    select
        nextval ('hibernate_sequence')
Hibernate: 
    insert 
    into
        Questionnaire
        (numero, publie, sexeDestinataire, titre, idQuestionnaire) 
    values
        (?, ?, ?, ?, ?)
Hibernate: 
    select
        nextval ('hibernate_sequence')
Hibernate: 
    insert 
    into
        Question
        (numQuestion, question, idQuestionnaire, typeReponse, idQuestion) 
    values
        (?, ?, ?, ?, ?)
WARN  - JDBCExceptionReporter      - SQL Error: 0, SQLState: 23503
ERROR - JDBCExceptionReporter      - L'élément du batch 0 insert into Question (numQuestion, question, idQuestionnaire, typeReponse, idQuestion) values ('1', 'question 1', '1', 'texte', '2') a été annulé. Appeler getNextException pour en connaître la cause.
WARN  - JDBCExceptionReporter      - SQL Error: 0, SQLState: 23503
ERROR - JDBCExceptionReporter      - ERROR: insert or update on table "question" violates foreign key constraint "fkbe5ca00676039098"
  Détail*: Key (idquestionnaire)=(1) is not present in table "questionnaire".
ERROR - tractFlushingEventListener - Could not synchronize database state with session
org.hibernate.exception.ConstraintViolationException: Could not execute JDBC batch update
	at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:96)
	at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66)
	at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:275)
	at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:262)
	at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:178)
	at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:321)
	at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:51)
	at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1206)
	at org.hibernate.ejb.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:791)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.springframework.orm.jpa.ExtendedEntityManagerCreator$ExtendedEntityManagerInvocationHandler.invoke(ExtendedEntityManagerCreator.java:365)
	at $Proxy30.flush(Unknown Source)
	at fr.statlife.protoE4N.data.dao.jpa.AbstractDaoJPAImpl.saveOne(AbstractDaoJPAImpl.java:45)
	at fr.statlife.protoE4N.data.dao.jpa.TestQuestionDao.startTransaction(TestQuestionDao.java:52)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
	at org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.java:74)
	at org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(RunAfterTestMethodCallbacks.java:82)
	at org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(SpringRepeat.java:72)
	at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:240)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
	at org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
	at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:70)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
	at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:180)
	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:49)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: java.sql.BatchUpdateException: L'élément du batch 0 insert into Question (numQuestion, question, idQuestionnaire, typeReponse, idQuestion) values ('1', 'question 1', '1', 'texte', '2') a été annulé. Appeler getNextException pour en connaître la cause.
	at org.postgresql.jdbc2.AbstractJdbc2Statement$BatchResultHandler.handleError(AbstractJdbc2Statement.java:2598)
	at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1836)
	at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:407)
	at org.postgresql.jdbc2.AbstractJdbc2Statement.executeBatch(AbstractJdbc2Statement.java:2737)
	at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:70)
	at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:268)
	... 42 more
INFO  - ionalTestExecutionListener - Rolled back transaction after test execution for test context [[TestContext@57398cac testClass = TestQuestionDao, locations = array<String>['classpath:/fr/statlife/protoE4N/data/dao/jpa/TestDao-context.xml'], testInstance = fr.statlife.protoE4N.data.dao.jpa.TestQuestionDao@3429cf1, testMethod = testFindAll@TestQuestionDao, testException = javax.persistence.PersistenceException: org.hibernate.exception.ConstraintViolationException: Could not execute JDBC batch update]]

on voit que les requêtes sont dans le bon ordre, il insert d'abord le questionnaire avant d'essayer d'insérer la question. ça ne rend le problème que plus incompréhensible pour moi en fait...

13/07/2011, 09h44
bboulch

Ok. Du coup je te conseille d'installer p6spy entre hibernate et le sgdb.

Il te fournira, en plus des requêtes SQL, le retour d'exécution et les valeurs assignées.
Je pense qu'avec le détail l'erreur paraitra évidente.

Benoit
13/07/2011, 10h04
zaboug

ok, merci pour la piste.
je vais tester ça de ce pas :)

bon, voilà les traces p6spy

Code:

1
2
3
4
5
6
7
8
9
1310547602989|3|0|//[creation de la base de données, et des différentes contraintes)]
1310547603006|17|0|statement||create sequence hibernate_sequence
1310547604095|25|1|statement|select nextval ('hibernate_sequence')|select nextval ('hibernate_sequence')
1310547604173|21|1|statement|insert into Questionnaire (numero, publie, sexeDestinataire, titre, idQuestionnaire) values (?, ?, ?, ?, ?)|insert into Questionnaire (numero, publie, sexeDestinataire, titre, idQuestionnaire) values ('Q1', '', 'b', 'Nutrition', 1)
1310547604185|2|2|statement|select nextval ('hibernate_sequence')|select nextval ('hibernate_sequence')
1310547604225|39|2|statement|insert into Question (numQuestion, question, idQuestionnaire, typeReponse, idQuestion) values (?, ?, ?, ?, ?)|insert into Question (numQuestion, question, idQuestionnaire, typeReponse, idQuestion) values (1, 'question 1', 1, 'texte', 2)
1310547604251|0|0|rollback||
1310547604258|5|1|rollback||
1310547604259|0|2|rollback||

si je me trompe pas, la troisième colonne correspond au numéro de la transaction, c'est bien ça?
donc on voit que les deux requêtes sont exécutées dans des transactions différentes, est ce que le problème peut venir de là?
Parce qu'au niveau des requêtes elles-même, je vois pas de problème avec les données...

13/07/2011, 19h22
bboulch

Citation:

Envoyé par zaboug

bon, voilà les traces p6spy

si je me trompe pas, la troisième colonne correspond au numéro de la transaction, c'est bien ça?

Peux-tu me dire où as tu eu cette information ? J'ai cherché mais sans trouver...

Bon, si ça correspond effectivement à la transaction, le problème peut venir de là (ex : manque un commit en fin de transaction, présence de 2 transactions au lieu d'une...). Peux-tu nous montrer le contenu de l'un des DAO ?

Je viens aussi de voir une différence dans le test : pour le questionnaire le "service" est appellé, pour la question, le "dao" est appellé. Est-ce que le souci ne pourrait pas venir de là ?

Benoit

Ps : je n'ai pas eu l'occassion d'utiliser l'annotation @Transactional, il se peut que certaines subtilités m'échappent...

Citation:

Envoyé par bboulch

Peux-tu me dire où as tu eu cette information ? J'ai cherché mais sans trouver...

je ne l'ai trouvé nulle part, simple déduction en fait, donc ça n'a peut être rien à voir :aie:

Citation:

Envoyé par bboulch

Bon, si ça correspond effectivement à la transaction, le problème peut venir de là (ex : manque un commit en fin de transaction, présence de 2 transactions au lieu d'une...). Peux-tu nous montrer le contenu de l'un des DAO ?

tous mes dao étendent la classe AbstractDao générique suivante:
Code:

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 public abstract class AbstractDaoJPAImpl<T extends DomainObject> implements Dao<T> { private Class<T> domainClass; @PersistenceContext(type=PersistenceContextType.EXTENDED) protected EntityManager em; public AbstractDaoJPAImpl(Class<T> domainClass) { this.domainClass = domainClass; } public void deleteOne(T object) { em.remove(object); em.flush(); } public T getOne(Serializable id) { return (T) em.find(domainClass, id); } public T saveOne(T object) { T entiteSauvee = em.merge(object); em.flush(); return entiteSauvee; } //getters and setters }
seule les méthodes findAll et countAll sont spécifiques à chaques dao, par exemple pour questionnaire :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 @Repository public class QuestionnaireDaoImpl extends AbstractDaoJPAImpl<Questionnaire> implements QuestionnaireDao { public QuestionnaireDaoImpl() { super(Questionnaire.class); } public List<Questionnaire> findAll() { TypedQuery<Questionnaire> query = em.createQuery("select q from Questionnaire q", Questionnaire.class); return query.getResultList(); } public int countAll() { TypedQuery<Long> query = em.createQuery("select count(*) from Questionnaire", Long.class); return (query.getSingleResult()).intValue(); } }
et c'est sur mes services que sont les transactions, par exemple pour le serviceQuestionnaire :
Code:

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 @Service public class ServiceQuestionnaireImpl implements ServiceQuestionnaire { @Resource private QuestionnaireDao questionnaireDao; @Resource private ServiceListeQuestionnaire serviceListeQuestionnaire; @Resource private ServiceMembre serviceMembre; @Transactional public void deleteOne(Questionnaire questionnaire) { questionnaireDao.deleteOne(questionnaire); } @Transactional public Questionnaire getOne(Serializable id) { return questionnaireDao.getOne(id); } @Transactional public List<Questionnaire> findAll() { return questionnaireDao.findAll(); } @Transactional public int countAll() { return questionnaireDao.countAll(); } @Transactional public Questionnaire saveOne(Questionnaire questionnaire) { return questionnaireDao.saveOne(questionnaire); } //autres méthodes
Citation:

Envoyé par bboulch

Je viens aussi de voir une différence dans le test : pour le questionnaire le "service" est appellé, pour la question, le "dao" est appellé. Est-ce que le souci ne pourrait pas venir de là ?

Benoit

Ps : je n'ai pas eu l'occassion d'utiliser l'annotation @Transactional, il se peut que certaines subtilités m'échappent...

j'ai aussi essayé en utilisant le dao de questionnaire à la place du service, mais ça ne change rien. Pour question, vu qu'on est dans la classe de tests unitaire de son dao, ça me semble logique d'utiliser le dao et pas le service (qui te toute manière ne fait qu'appeler le dao :))

Merci de ton aide en tous cas, c'est plus facile de chercher à deux cerveaux (surtout que ça fait trois jours que les recherches avec mon seul cerveau sont complètement infructueuses :cry:)

14/07/2011, 22h34
bboulch

Citation:

Pour question, vu qu'on est dans la classe de tests unitaire de son dao, ça me semble logique d'utiliser le dao et pas le service

Ca me parait pas mal. Faut juste qu'il y ait un gestionnaire de transaction qui chapotte le test ou le DAO (ce que j'ai cru voir dans le test unitaire).

Sur la page http://www.astorm.ch/blog/index.php?...n-%40OneToManyj , juste sous la partie qui parle de l'attribut "mappedBy", il parle d'une subtilité qui n'est pas retrouvé ici dans le test unitaire. Cette subtilité est d'ajouter la question au questionnaire avant de faire l'appel au DAO de la question.

Benoit

merci pour le lien !
en effet, j'avais pas fait l'ajout de l'objet question à la collection de Question du questionnaire.
En suivant l'exemple du lien que tu m'as donné, j'ai commencé par testé ça :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
	@Before
	@Transactional
	public void startTransaction() throws ParseException{
		Questionnaire q1 = new Questionnaire();
		q1.setNumero("Q1");
		q1.setTitre("Nutrition");
		q1.setSexeDestinataire('b');
 
		Question question1 = new Question();
		question1.setNumQuestion(1);
		question1.setQuestion("question 1");
		question1.setTypeReponse("texte");
 
 
		//Mise à jour des références
		question1.setQuestionnaire(q1);
		q1.getListeQuestions().add(question1);
 
		//persistence du tout
		questionnaire = serviceQuestionnaire.saveOne(q1);
		question = questionDao.saveOne(question1);
	}

Mais j'ai obtenu l'erreur suivante :

Code:

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
java.lang.IllegalStateException: org.hibernate.TransientObjectException: object is an unsaved transient instance - save the transient instance before merging: fr.statlife.protoE4N.data.entites.Question
	at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1232)
	at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1168)
	at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1174)
	at org.hibernate.ejb.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:691)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.springframework.orm.jpa.ExtendedEntityManagerCreator$ExtendedEntityManagerInvocationHandler.invoke(ExtendedEntityManagerCreator.java:365)
	at $Proxy30.merge(Unknown Source)
	at fr.statlife.protoE4N.data.dao.jpa.AbstractDaoJPAImpl.saveOne(AbstractDaoJPAImpl.java:44)
	at fr.statlife.protoE4N.metier.ServiceQuestionnaireImpl.saveOne(ServiceQuestionnaireImpl.java:54)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:309)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
	at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:110)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
	at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
	at $Proxy38.saveOne(Unknown Source)
	at fr.statlife.protoE4N.data.dao.jpa.TestQuestionDao.startTransaction(TestQuestionDao.java:56)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
	at org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.java:74)
	at org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(RunAfterTestMethodCallbacks.java:82)
	at org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(SpringRepeat.java:72)
	at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:240)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
	at org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
	at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:70)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
	at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:180)
	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:49)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: org.hibernate.TransientObjectException: object is an unsaved transient instance - save the transient instance before merging: fr.statlife.protoE4N.data.entites.Question
	at org.hibernate.event.def.DefaultMergeEventListener.getTransientCopyCache(DefaultMergeEventListener.java:142)
	at org.hibernate.event.def.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:90)
	at org.hibernate.impl.SessionImpl.fireMerge(SessionImpl.java:859)
	at org.hibernate.impl.SessionImpl.merge(SessionImpl.java:843)
	at org.hibernate.impl.SessionImpl.merge(SessionImpl.java:847)
	at org.hibernate.ejb.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:682)
	... 48 more

en gros il est pas content que j'essaie d'ajouter une question qui fait pas partie du contexte de persistance au questionnaire.

Bon, cela dit, j'ai remarqué que dans l'exemple, pour persister ses objets, il utilise des em.persist() et non des em.merge() comme je le fais .
Alors j'ai essayé en utilisant moi aussi persist à la place de merge, histoire de voir si ça changeait quelque chose. La méthode saveOne de mon dao générique devient donc :

Code:

1
2
3
4
5
6
7
8
public T saveOne(T object)
{
	//T entiteSauvee = em.merge(object);
	em.persist(object);
	em.flush();
 
	return object;
}

Avec ce code, plus d'erreur de type TransientObjectException, par contre je retrouve mon erreur du début

Code:

1
2
3
4
5
6
7
WARN  - JDBCExceptionReporter      - SQL Error: 0, SQLState: 23503
ERROR - JDBCExceptionReporter      - L'élément du batch 0 insert into Question (numQuestion, question, idQuestionnaire, typeReponse, idQuestion) values ('1', 'question 1', '1', 'texte', '2') a été annulé. Appeler getNextException pour en connaître la cause.
WARN  - JDBCExceptionReporter      - SQL Error: 0, SQLState: 23503
ERROR - JDBCExceptionReporter      - ERROR: insert or update on table "question" violates foreign key constraint "fkbe5ca00676039098"
  Détail*: Key (idquestionnaire)=(1) is not present in table "questionnaire".
ERROR - tractFlushingEventListener - Could not synchronize database state with session
[...]

C'est con, j'avais bon espoir que la piste soit la bonne, mais c'est retour à la case départ :(

15/07/2011, 10h13
bboulch

Une piste simple mais à ne pas suivre : supprimer définitivement la foreign key.

Sinon, les requêtes SQL dans p6spy sont toujours les mêmes ?
As-tu regardé le comportement des données en base au fur et à mesure de l'exécution du test unitaire ? Ca pourrait peut être te donner une éventuelle piste...

Benoit

ps : j'ai cru lire hier soir sur une autre page web que la foreign key devait pouvoir prendre la valeur null (l'idée était qu'hibernate fait un insert de la question, du questionnaire puis met à jour la question avec l'id du questionnaire). En fait, supprimer la foreign key uniquement afin de voir comment se comporte hibernate sans elle, ça peut être une autre piste à suivre. Et voir comment la ré-activer ensuite.
15/07/2011, 10h54
Rei Ichido

Il me semble que tu devrais essayer de changer ta propagation, pour CascadeType.ALL dans un premier temps (selon ce que tu comptes faire), et puis ensuite si tu le souhaites tu peux affiner.

merci à vous deux pour vos propositions.
Après différents essais, c'est pas encore ça mais y'a du mieux :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
@Before
@Transactional
public void startTransaction() throws ParseException{
	Questionnaire q1 = new Questionnaire();
	q1.setNumero("Q1");
	q1.setTitre("Nutrition");
	q1.setSexeDestinataire('b');
	questionnaire = serviceQuestionnaire.saveOne(q1);
 
	Question question1 = new Question();
	question1.setNumQuestion(1);
	question1.setQuestion("question 1");
	question1.setTypeReponse("texte");
	question = questionDao.saveOne(question1);
 
	//Mise à jour des références
	question.setQuestionnaire(questionnaire);
	questionnaire.getListeQuestions().add(question);
}

Ce code passe sans problème (que le cascadeType soit en ALL ou juste en REMOVE).
Donc maintenant, c'est au niveau de certains tests que ça pète :

Code:

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
@Test
@Transactional
@Rollback
public void testFindAll() {
	List<Question> questionsAttendus = new ArrayList<Question>();
	questionsAttendus.add(question);
 
	Assert.assertEquals(questionsAttendus, questionDao.findAll());
}
 
@Test @Transactional
@Rollback
public void testCountAll() {
	Assert.assertEquals(1, questionDao.countAll());
}
 
@Test @Transactional
@Rollback
public void testDelete() {
	questionDao.deleteOne(question);
	Assert.assertEquals(0, questionDao.countAll());
}
 
@Test @Transactional
@Rollback
public void testLoad() {
	Question question2 = questionDao.getOne(question.getIdQuestion());
	Assert.assertEquals(question, question2);
}

Les tests load et delete passent. Et j'ai vérifié les requêtes via p6spy, elles sont cohérentes.
Par contre les tests findAll et countAll passent pas. J'ai la même exception qu'avant :

Code:

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
javax.persistence.PersistenceException: org.hibernate.exception.ConstraintViolationException: Could not execute JDBC batch update
	at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1235)
	at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1168)
	at org.hibernate.ejb.QueryImpl.getResultList(QueryImpl.java:250)
	at fr.statlife.protoE4N.data.dao.jpa.QuestionDaoImpl.findAll(QuestionDaoImpl.java:22)
	at fr.statlife.protoE4N.data.dao.jpa.TestQuestionDao.testFindAll(TestQuestionDao.java:66)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
	at org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.java:74)
	at org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(RunAfterTestMethodCallbacks.java:82)
	at org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(SpringRepeat.java:72)
	at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:240)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
	at org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
	at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:70)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
	at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:180)
	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:49)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: org.hibernate.exception.ConstraintViolationException: Could not execute JDBC batch update
	at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:96)
	at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66)
	at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:275)
	at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:262)
	at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:179)
	at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:321)
	at org.hibernate.event.def.DefaultAutoFlushEventListener.onAutoFlush(DefaultAutoFlushEventListener.java:64)
	at org.hibernate.impl.SessionImpl.autoFlushIfRequired(SessionImpl.java:1175)
	at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1251)
	at org.hibernate.impl.QueryImpl.list(QueryImpl.java:102)
	at org.hibernate.ejb.QueryImpl.getResultList(QueryImpl.java:241)
	... 31 more
Caused by: java.sql.BatchUpdateException: L'élément du batch 0 update Question set numQuestion='1', question='question 1', idQuestionnaire='1', typeReponse='texte' where idQuestion='2' a été annulé. Appeler getNextException pour en connaître la cause.
	at org.postgresql.jdbc2.AbstractJdbc2Statement$BatchResultHandler.handleError(AbstractJdbc2Statement.java:2598)
	at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1836)
	at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:407)
	at org.postgresql.jdbc2.AbstractJdbc2Statement.executeBatch(AbstractJdbc2Statement.java:2737)
	at com.p6spy.engine.logging.P6LogPreparedStatement.executeBatch(P6LogPreparedStatement.java:329)
	at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:70)
	at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:268)
	... 39 more

sauf que cette fois elle apparait au moment du query.getResultList() des méthodes findAll et countAll du dao :

Code:

1
2
3
4
5
6
7
8
9
10
11
 
public List<Question> findAll() {
	TypedQuery<Question> query = em.createQuery("select q from Question q", Question.class);
	return query.getResultList();
}
 
public int countAll() {
	TypedQuery<Long> query = em.createQuery("select count(*) from Question", Long.class);
 
	return (query.getSingleResult()).intValue();
}

en fait, dans la trace de l'exception, on se rend compte qu'à ce moment il y a un flush qui est fait, une requête update sur question est envoyée (merci p6spy) et c'est elle qui foire. Encore une fois, il dit que le questionnaire est pas en base, alors qu'en toute logique, si, il devrait y être...

Citation:

As-tu regardé le comportement des données en base au fur et à mesure de l'exécution du test unitaire ? Ca pourrait peut être te donner une éventuelle piste...

J'ai essayé plusieurs fois, mais je dois mal m'y prendre j'imagine car j'y arrive pas :aie: Je m'explique : quand je mets des breaks dans le déroulement des tests, que je les lance en debug (j'utilise Eclipse Helios), et que je vais voir ce qui se passe dans ma base de données, bah il se passe rien, y'a pas de données dans la base :?
Pour aller voir en base, j'utilise le client pgAdminIII.
Je sais pas si ça veut dire qu'il y a réellement rien dans la base (auquel cas c'est normal qu'il m'envoie cette exception depuis le début :aie:) ou si c'est que je m'y prends mal pour essayer d'aller voir ce qu'il se passe dans la base de données. Je penchais plus vers cette deuxième option, mais j'ai peut être eu tort ?
Comment vous faites vous pour aller voir dans la base de données en cours de test?

15/07/2011, 13h18
bboulch

Pour aller voir en base, ta démarche me parait pas mal.
Par contre, sur mon ancien SGBD, les données n'étaient pas présentes en base tant que le commit n'avait pas eu lieu. Et la présence de @Rollback me laisse penser que tout est roll-backer en fin de test.

La présence d'un "update" lors d'un "select" me laisse perplexe.

J'ai une solution un peu lourde à te proposer : séparer la classe de tests en plusieurs classes. Et retirer l'annotation @rollback.

Tu pourras ainsi t'assurer dans un test qu'un insert simple d'un questionnaire fonctionne et qu'il est bien présent en base en fin de test. Ensuite tu pourras faire le même constat dans un autre test pour le questionnaire et une question. Et pour finir tu pourras tester les countAll().

Mais une autre personne aura peut être une solution plus simple à te proposer.

Benoit
15/07/2011, 13h39
Rei Ichido

Citation:

Envoyé par bboulch

Pour aller voir en base, ta démarche me parait pas mal.
Par contre, sur mon ancien SGBD, les données n'étaient pas présentes en base tant que le commit n'avait pas eu lieu. Et la présence de @Rollback me laisse penser que tout est roll-backer en fin de test.

C'est le comportement normal d'un SGBD, de ne pas valider les modifications tant qu'il n'y a pas eu un commit.
Et en effet, l'annotation @Rollback signifie qu'il y aura un rollback en fin de méthode de test, ce qui veut dire que si c'est créé dans une méthode, une autre méthode ne la trouvera pas en base ...
15/07/2011, 13h59
zaboug
oui, je connaissais le role du rollback, c'est pour ça que je mettais mes breaks dans la méthode startTransaction, avant tout rollback.
Par contre j'avais oublié pour le commit. Cela dit, le commit est fait en fin de transaction si je me souviens bien (j'utilise spring, donc il n'y a pas de commit explicite dans mon code), donc vu que je plaçais mes breaks après le questionnaire = serviceQuestionnaire.saveOne(q1); (par exemple), le questionnaire aurait du apparaitre en base, non?

Bon, toujours est-il que j'ai testé un peu à la manière de la proposition de Bboulch : j'ai laissé la méthode startTransaction telle quelle, mais j'ai commenté tous les tests sauf testLoad dont j'ai commenté l'annotation rollback:
Code:

1 2 3 4 5 6 @Test @Transactional //@Rollback public void testLoad() { Question question2 = questionDao.getOne(question.getIdQuestion()); Assert.assertEquals(question, question2); }
J'ai mis un breakpoint au niveau de la ligne 5 du code ci-dessus et je suis allée voir dans la base via pgAdmin. C'est bizarre car la sequence "hibernate_sequence" a bien été incrémentée (valeur au moment du breackpoint : 2), mais qu'aucune donnée n'apparait en base que ce soit dans la table QUESTION ou dans la table QUESTIONNAIRE...
EDIT : au moment du breakpoint, les requêtes insert n'apparaissent pas encore dans les logs p6spy, ce qui pourrait expliquer qu'on trouve rien dans la base de données...
Reste à savoir pourquoi les requêtes sont pas exécutées avant le breakpoint?
Je continue de chercher...
15/07/2011, 14h09
zaboug

Re-EDIT : en fait si, les requêtes insert apparaissent bien dans les log au moment du breakpoint, c'est juste que le fichier avait pas du bien être rechargé la première fois que j'ai checké...
Par contre, toujours rien en base :?
15/07/2011, 14h11
bboulch

Euh, es-tu sûr du code affiché ? Je ne vois pas pourquoi la séquence serait incrementée pour une lecture.

Les données apparaitront en base une fois le commit fait. Quand est-ce que Spring se charge de le faire ?

Vu que le "rollback" est présent dans les logs de p6spy, le "commit" devrait peut être aussi apparaitre. Et les données seront présentes en base après que le commit "fût" affiché.

Courage !

Benoit
15/07/2011, 14h12
zaboug

non, le commit n'apparait pas dans les logs...
je vais chercher dans la doc de spring.

La séquence hibernate a été utilisée à cause du @Before : la méthode startTransaction est appelée avant chaque test, ce qui peut d'ailleurs être la source d'un problème de clé primaire.

Ensuite, le commit arrive théoriquement au sortir d'une méthode @Transactionnal, sauf si une Exception a été levée (ou que la transaction reste en vie parce qu'elle était issue d'une autre méthode transactionnelle et qu'il y a eu propagation). Le TransactionManager est bien déclaré dans la config Spring ?

Au sujet du CascadeType.ALL, ça permet surtout de faire du code de ce genre :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 @Before @Transactional public void startTransaction() throws ParseException{ Questionnaire q1 = new Questionnaire(); q1.setNumero("Q1"); q1.setTitre("Nutrition"); q1.setSexeDestinataire('b'); Question question1 = new Question(); question1.setNumQuestion(1); question1.setQuestion("question 1"); question1.setTypeReponse("texte"); //Mise à jour des références question.setQuestionnaire(questionnaire); questionnaire.getListeQuestions().add(question); // La sauvegarde du questionnaire sauvegarde aussi la question questionnaire = serviceQuestionnaire.saveOne(q1); }

oui, la méthode startTransaction (qui pourrait s'appeler setup d'ailleurs) est appelée avant chaque test. Mais a priori ça ne pose pas de problème vu qu'il y a un rollback après chaque test...

pour le commit, j'en étais arrivé à cette conclusion en relisant la doc spring. J'ai aussi remarqué la présence du mode autocommit = true dans les traces :
Code:

1 2 3 INFO - rManagerConnectionProvider - Using Hibernate built-in connection pool (not for production use!) INFO - rManagerConnectionProvider - Hibernate connection pool size: 20 INFO - rManagerConnectionProvider - autocommit mode: true
si j'ai bien compris, ça veut dire qu'il y a un commit de fait à chaque requête SQL. Mais j'ai pas encore creusé de ce côté là (je crois que c'est comme ça par défaut car j'ai pas trouvé d'endroit où je dis explicitement d'avoir un autocommit à true dans mes fichiers de config.

pour ce qui est de la config de spring, oui, j'ai vérifié et le transaction manager est bien spécifié :
Code:

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 <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:tx="http://www.springframework.org/schema/tx" xmlns:context="http://www.springframework.org/schema/context" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-3.0.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd" default-autowire="byName"> <bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalEntityManagerFactoryBean"> <property name="persistenceUnitName" value="jpaUnitProtoE4N" /> </bean> <bean id="transactionManager" class="org.springframework.orm.jpa.JpaTransactionManager"> <property name="entityManagerFactory" ref="entityManagerFactory" /> </bean>  <tx:annotation-driven transaction-manager="transactionManager" />  <context:annotation-config /> <context:component-scan base-package="fr.statlife.protoE4N" /> </beans>
pour ce qui est du cascade.ALL, en effet, il y a du mieux : je n'ai plus l'erreur de foreign key en faisant comme tu proposes. Par contre, aucun test ne passe :

le findAll renvoie une liste vide
le countAll renvoie 0
le load marche pas vu que l'id de question n'est pas mis à jour => l'id est généré automatiquement pas hibernate, et vu que je fais pas de save explicite, bah dans question l'id est resté à null...

donc au final, y'a plus l'exception mais j'ai pas l'impression que ça remplisse la base (j'arrive toujours pas à regarder directement dedans via pgAdmin...) pour autant...
et avec cette méthode, je vois pas comment avoir mon objet question à jour. d'ailleurs, vu que j'ajoute le questionnaire à la question avant que le questionnaire soit persisté, dans question l'idQuestionnaire aussi reste à null.
Bref, on dirait pas que le cascade.ALL mette réellement à jour le contexte... ou alors c'est qu'il faut appeler une méthode derrière pour avoir bien le tout à jour, mais je vois pas laquelle...

15/07/2011, 15h39
Rei Ichido

Citation:

Envoyé par zaboug

oui, la méthode startTransaction (qui pourrait s'appeler setup d'ailleurs) est appelée avant chaque test. Mais a priori ça ne pose pas de problème vu qu'il y a un rollback après chaque test...

Attention, normalement le rollback n'affecte que la transaction en cours ! Celle qui est lancée par le Before ne devrait pas être affectée.

Ce qui fait que l'absence de commit est très mystérieuse pour moi :?

Tu peux montrer ta config hibernate ?

euh bah je sais pas pour le startTransaction du coup, mais j'ai fait comme ça pour chacun de mes tests sans avoir de souci sur les clés primaires en fait...

crois tu vraiment qu'il n'y a pas de commit du tout? je pensais qu'avec la trace autocommit:true il y avait un commit implicite à chaque fin de transaction. Ce que je ne m'explique pas, c'est pourquoi je vois pas ce qu'il y a en base pendant les tests. Mais je me demande si l'utilisation de spring joue pas à ce niveau avec l'annotation @RunWith(SpringJUnit4ClassRunner.class) sur la classe.

voici mon fichier de conf hibernate :

Code:

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
<?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns="http://java.sun.com/xml/ns/persistence"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
      http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd"
	version="2.0">
 
	<!-- A JPA Persistence Unit -->
	<persistence-unit name="jpaUnitProtoE4N" transaction-type="RESOURCE_LOCAL">
		<provider>org.hibernate.ejb.HibernatePersistence</provider>
 
		<properties>
			<property name="hibernate.dialect" value="org.hibernate.dialect.PostgreSQLDialect" />
		<!-- <property name="hibernate.connection.driver_class" value="org.postgresql.Driver"></property> -->
			<property name="hibernate.connection.driver_class" value="com.p6spy.engine.spy.P6SpyDriver"></property>
			<property name="hibernate.connection.url" value="jdbc:postgresql://localhost:5432/protoE4N"></property>
			<property name="hibernate.connection.username" value="appliE4N" />
			<property name="hibernate.connection.password" value="pwdAppliE4N" />
			<property name="hibernate.show_sql" value="true" />
			<property name="hibernate.format_sql" value="true"/>
 
			<!-- value create permet de créer la base de données à l'initialisation de l'unité JPA
			Il faudra modifier cette valeur avant la mise en production -->
			<property name="hibernate.hbm2ddl.auto" value="create" />
 
		</properties>
	</persistence-unit>
 
</persistence>

15/07/2011, 15h57
Rei Ichido

Citation:

Envoyé par zaboug

crois tu vraiment qu'il n'y a pas de commit du tout? je pensais qu'avec la trace autocommit:true il y avait un commit implicite à chaque fin de transaction. Ce que je ne m'explique pas, c'est pourquoi je vois pas ce qu'il y a en base pendant les tests. Mais je me demande si l'utilisation de spring joue pas à ce niveau avec l'annotation @RunWith(SpringJUnit4ClassRunner.class) sur la classe.

Ah bein oui, ça vient probablement de là ^^'

Citation:

If you want a transaction to commit - unusual, but occasionally useful when you want a particular test to populate or modify the database - the Spring integration testing support frameworks can be instructed to cause the transaction to commit instead of roll back either by calling an inherited hook-method or by declaring a specific annotation.

=> Ta méthode crée bien un objet Questionnaire avec sa Question, mais il est rollbacké et non pas commité à la fin de ta méthode !
15/07/2011, 16h02
zaboug

gniark ! quel boulet je suis !!
bon bah y'a plus qu'à trouver l'annotation qui va bien pour lui dire de committer à cet empaffé de spring ;)

merci en tout cas, je pouvais chercher dans la mauvaise direction encore longtemps !!

bon bah c'est pas encore gagné...
j'ai suivi un exemple donné dans la doc pour aboutir au résultat suivant :
Code:

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 @RunWith(SpringJUnit4ClassRunner.class) @ContextConfiguration("TestDao-context.xml") @DirtiesContext @TransactionConfiguration(defaultRollback=false) @Transactional public class TestQuestionDao { [...] @Before //@Transactional public void startTransaction() throws ParseException{ //pas de changement dans le corps de la méthode } @Test //@Transactional @Rollback(true) public void testFindAll() { List<Question> questionsAttendus = new ArrayList<Question>(); questionsAttendus.add(question); Assert.assertEquals(questionsAttendus, questionDao.findAll()); } @Test// @Transactional @Rollback(true) public void testCountAll() { Assert.assertEquals(1, questionDao.countAll()); } //etc }
mais je vois toujours pas les données dans ma base ! pourtant dans la doc il est dit :

Citation:

To control whether or not a transaction should commit for a particular test method, you may use the @Rollback annotation to override the class-level default rollback setting.

donc avec l'annotation @TransactionConfiguration(defaultRollback=false) et le fait que j'ai pas mis de rollback sur la methode startTransaction, bah ça devrait être committé...
Je sais pas si c'est la fatigue ou quoi, mais j'ai l'impression de passer à côté de quelque chose d'évident sans le voir :?

15/07/2011, 16h42
Rei Ichido

Si tu lis la doc, il dit que le @Before est en fait inclus dans la Transaction de ton @Transactionnal, contrairement au @BeforeTransaction de mes souvenirs :aie:

D'où le fait que ça ne soit en fait pas commité, vu que tes méthodes testées sont en @Rollback=true.

Par contre, les tests devraient bien se passer ?
15/07/2011, 17h37
zaboug

EDIT : Autant pour moi, avec l'annotation @BeforeTransaction la base de données se remplit bien.
Par contre, comment faire pour obtenir l'objet question à jour vu qu'il est enregistré via le cascade.ALL?
car là les tests passent pas mais parce que j'ai pas l'objet question dans le bon état...

Déjà, est-ce que tu peux essayer de passer en @BeforeTransaction (et donc en remettant un @Transactionnal), en mettant ensuite un @AfterTransaction qui lui irait supprimer la ligne ? Comme ça on sera sûr que si le commit est effectué, ça se passe bien, et que ce n'est pas une question d'interactions dans les transactions.

EDIT : ouais je suis pas rapide quand j'écris un post, ça peut facilement se croiser ^^'
Par contre, tu stockes où ton questionnaire ? Dans le code que j'ai vu, c'était une variable locale (et donc, normal de ne pas avoir quoi que ce soit pour le retrouver par l'id).
Ah, je viens de relire le code, et effectivement il y a un problème entre q1 et questionnaire, non ? Parce qu'il faudrait mettre à jour q1 :
Code:

1 2 3 4 5 6 7 //Mise à jour des références question.setQuestionnaire(q1); q1.getListeQuestions().add(question); // La sauvegarde du questionnaire sauvegarde aussi la question questionnaire = serviceQuestionnaire.saveOne(q1);
Ce qui permet de sauvegarder proprement q1, et le saveOne doit retourner un objet tout propre avec son id.

oui, le questionnaire obtenu est le bon, j'ai pas de problème avec le questionnaire en fait, mais avec la question.
Le but de cette classe de test est de tester le dao de l'entité Question.

J'ai finalement réussi à faire passer les tests findAll, countAll et load en ajoutant la ligne question = questionnaire.getListeQuestions().get(0); à la fin de la méthode startTransaction. Comme ça je récupère l'objet question tel qu'il est. Mais ça me semble bancale comme approche, d'autant plus que le test delete marche pas et lance une exception qui dit que je peux pas supprimer un objet détaché :

Code:

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
java.lang.IllegalArgumentException: Removing a detached instance fr.statlife.protoE4N.data.entites.Question#6
	at org.hibernate.ejb.event.EJB3DeleteEventListener.performDetachedEntityDeletionCheck(EJB3DeleteEventListener.java:65)
	at org.hibernate.event.def.DefaultDeleteEventListener.onDelete(DefaultDeleteEventListener.java:108)
	at org.hibernate.event.def.DefaultDeleteEventListener.onDelete(DefaultDeleteEventListener.java:74)
	at org.hibernate.impl.SessionImpl.fireDelete(SessionImpl.java:948)
	at org.hibernate.impl.SessionImpl.delete(SessionImpl.java:926)
	at org.hibernate.ejb.AbstractEntityManagerImpl.remove(AbstractEntityManagerImpl.java:698)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.springframework.orm.jpa.ExtendedEntityManagerCreator$ExtendedEntityManagerInvocationHandler.invoke(ExtendedEntityManagerCreator.java:365)
	at $Proxy32.remove(Unknown Source)
	at fr.statlife.protoE4N.data.dao.jpa.AbstractDaoJPAImpl.deleteOne(AbstractDaoJPAImpl.java:33)
	at fr.statlife.protoE4N.data.dao.jpa.TestQuestionDao.testDelete(TestQuestionDao.java:86)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
	at org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.java:74)
	at org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(RunAfterTestMethodCallbacks.java:82)
	at org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(SpringRepeat.java:72)
	at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:240)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
	at org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
	at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:70)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
	at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:180)
	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:49)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)

du coup, comment faire pour récupérer l'objet question persisté s'il a été sauvegardé via le cascadeType.ALL?

EDIT :
bon, tous les tests passent mais je trouve ma manière de faire un peu lourde :

Code:

1
2
3
	questionnaire = serviceQuestionnaire.saveOne(q1);
	question = questionnaire.getListeQuestions().get(0);
	question = questionDao.getOne(question.getIdQuestion());

s'il y a un moyen de faire ça plus proprement, je suis preneuse :aie:

Cela dit, maintenant tous les tests passent :ccool:
Un GRAAANNNND merci à vous deux pour votre aide et votre patience :mouarf: