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

**zaboug** · 15/07/2011, 14h12

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

**Rei Ichido** · 15/07/2011, 14h48

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 :

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
 
@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);
 
}

**zaboug** · 15/07/2011, 15h21

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 :

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

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 :

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
<?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>
 
	<!--
		enable the configuration of transactional behavior based on
		annotations
	-->
	<tx:annotation-driven transaction-manager="transactionManager" />
 
 
	<!-- Configuration par annotations -->
	<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...

**Rei Ichido** · 15/07/2011, 15h39

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 ?

**zaboug** · 15/07/2011, 15h45

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 :

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
<?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>

**Rei Ichido** · 15/07/2011, 15h57

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à ^^'

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 !

**zaboug** · 15/07/2011, 16h02

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 !!

**zaboug** · 15/07/2011, 16h26

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

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
@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 :

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

**Rei Ichido** · 15/07/2011, 16h42

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

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 ?

**zaboug** · 15/07/2011, 17h37

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...

**Rei Ichido** · 15/07/2011, 17h44

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 :

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

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.

**zaboug** · 15/07/2011, 18h00

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 :

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
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 :

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

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

Cela dit, maintenant tous les tests passent

Un GRAAANNNND merci à vous deux pour votre aide et votre patience

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

Hibernate Java

Discussions similaires

Partager

Partager