Nous avons deux tables: SitesAddress et SitesAccessPoint reliée en n,n par une troisième table SitesAccessPointSitesAddress.
Les liens sont les suivants et sont configurés en cascade delete :
SitesAddress sitesAcpAdrAdrId Cascade delete 0,n
Malgré cette configuration, il nous est impossible de supprimer nos SitesAddress liées à des SitesAccessPoint, nous avons l’erreur suivante (dans les logs /ui/logs si on tente de supprimer via l’IHM, ou directement dans /ext/DBAccess si on tente un DELETE direct en base) : update or delete on table “sites_address” violates foreign key constraint “sitesaccesspoint_sitesaddress_acpadr_adr_id_fkc” on table “sitesaccesspoint_sitesaddress” Detail: Key (row_id)=(64210) is still referenced from table “sitesaccesspoint_sitesaddress”.
Bon déjà faire un delete en base n’est vraiment pas recommandé, là j’imagine que c’était pour vérifier si le message remonté était bien lié à une intégrité en base…
Tel que vous me décrivez votre configuration ça devrait pourtant marcher, en demandant la suppression de d’un record de l’objet métier SiteAddress les records liés de l’objet de relation SitesAccessPointSitesAddress reférençant le row ID du record SiteAddress devraient être supprimés en premier, ensuite seulement le record de SiteAddress devrait être supprimé.
A mon avis vous devez avoir un pb à la suppression des records de l’objet SitesAccessPointSitesAddress, il doit y avoir plus d’infos dans les logs.
Pour ce genre de demande merci de systématiquement nous indiquer la version et la révision de votre instance (que vous obtenez en appelant /health), et nous fournir les extraits de logs complets qui concernent le pb que vous décrivez, d’éventuellement nous fournir le modèle logique des objets métier dont on parle (c’est souvent plus simple que de le décrire textuellement), etc.
Avoir ces infos nous permet de:
commencer par regarder les logs pour voir si quelque chose de bizarre nous saute aux yeux
si ça ne suffit pas, reproduire un cas de test similaire sur une instance de même version et même révision
etc.
2019-11-04 17:09:33,726 ERROR [com.simplicite.util.engine.ObjectManager] SIMPLICITE|http://3dfaba09cf40:8080||ECOREDB001|system|com.simplicite.util.engine.ObjectManager|update||Error SQL query: jdbc/simplicite: delete from sites_address where row_id=?
org.postgresql.util.PSQLException: ERROR: update or delete on table "sites_address" violates foreign key constraint "sitesaccesspoint_sitesaddress_acpadr_adr_id_fkc" on table "sitesaccesspoint_sitesaddress"
Detail: Key (row_id)=(66283) is still referenced from table "sitesaccesspoint_sitesaddress".
at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2497)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2233)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:310)
at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:446)
at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:370)
at org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:149)
at org.postgresql.jdbc.PgPreparedStatement.executeUpdate(PgPreparedStatement.java:124)
at org.apache.tomcat.dbcp.dbcp2.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:136)
at org.apache.tomcat.dbcp.dbcp2.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:136)
at com.simplicite.util.engine.DBAccess.update(DBAccess.java:1528)
at com.simplicite.util.engine.DBAccess.update(DBAccess.java:1492)
at com.simplicite.util.engine.ObjectManager.deleteObj(ObjectManager.java:3860)
at com.simplicite.util.engine.ObjectManager.delete(ObjectManager.java:3637)
at com.simplicite.util.ObjectDirect.delete(ObjectDirect.java:543)
at com.simplicite.util.ObjectDB.delete(ObjectDB.java:1511)
at com.simplicite.webapp.tools.JSONServletTool.deleteAll(JSONServletTool.java:1196)
at com.simplicite.webapp.ObjectJson.deleteAll(ObjectJson.java:414)
at com.simplicite.webapp.tools.JSONServletTool.businessObjectService(JSONServletTool.java:547)
at com.simplicite.webapp.servlets.AbstractJSONServlet.service(AbstractJSONServlet.java:68)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at com.simplicite.webapp.filters.AuthMethodFilter.doFilter(AuthMethodFilter.java:115)
at com.simplicite.webapp.filters.AbstractFilter.doFilter(AbstractFilter.java:37)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at com.simplicite.webapp.filters.RewriteFilter.doFilter(RewriteFilter.java:77)
at com.simplicite.webapp.filters.AbstractFilter.doFilter(AbstractFilter.java:37)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:202)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:526)
at com.simplicite.tomcat.valves.APISessionValve.invoke(Unknown Source)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:678)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:408)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:861)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1579)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.base/java.lang.Thread.run(Thread.java:830)
Merci pour ces éléments. Pour les logs ce qui est intéressant c’est d’avoir les logs qui précèdent la log qui indique le pb “violated constraint” car si on a ce pb là c’est sans doute que ce qui se passe avant a rencontré un autre pb.
C’est l’intégralité des logs correspondants sachant qu’on a le niveau de log à “ERROR” étant donné que ce problème arrive sur notre environnement de production. A quel niveau de logs sont les logs qui sont susceptibles d’être utiles ?
En fait ce qu’il nous faut c’est l’ensemble des logs (info, warning, error, fatal) générées entre le clic sur le bouton delete et le moment où ça rend la main.
Ce que je soupçonne c’est que les suppressions sur votre objet de relation ne se passent pas bien pour une raison qu’il faut identifier.
Ensuite, forcément, vous avez votre erreur d’intégrité. Mais celle-ci n’est pas la cause c’est juste une conséquence, ce qu’il faut comprendre c’est la cause et ça c’est peut être indiqué dans les logs générées avant votre erreur d’intégrité.
Voici l’ensemble des logs, il n’y a pas une information de plus :
019-11-04 18:13:26,535 INFO [com.simplicite.util.Grant] SIMPLICITE|http://3dfaba09cf40:8080||ICORED0001|public|com.simplicite.util.Grant|init||Info: public connected using curl/7.29.0, timeout = 1800s
2019-11-04 18:13:26,526 INFO [Logon] SIMPLICITE|http://3dfaba09cf40:8080||SESSION|public|Logon|login (direct)||Session utilisateur=public/7E677360CB03F9C9929368BEC5AB3FE8 time=0
2019-11-04 18:13:06,592 INFO [com.simplicite.util.Grant] SIMPLICITE|http://3dfaba09cf40:8080||ICORED0001|public|com.simplicite.util.Grant|init||Info: public connected using Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.87 Safari/537.36, timeout = 1800s
2019-11-04 18:13:06,582 INFO [Logon] SIMPLICITE|http://3dfaba09cf40:8080||SESSION|public|Logon|login (direct)||Session utilisateur=public/104421F536FBAAAA3483FBC8F267F881 time=0
2019-11-04 18:12:56,380 INFO [com.simplicite.util.Grant] SIMPLICITE|http://3dfaba09cf40:8080||ICORED0001|public|com.simplicite.util.Grant|init||Info: public connected using curl/7.29.0, timeout = 1800s
2019-11-04 18:12:56,360 INFO [Logon] SIMPLICITE|http://3dfaba09cf40:8080||SESSION|public|Logon|login (direct)||Session utilisateur=public/28B8A7061DE9A8E407ED001597B2F1B3 time=0
2019-11-04 18:12:26,210 INFO [com.simplicite.util.Grant] SIMPLICITE|http://3dfaba09cf40:8080||ICORED0001|public|com.simplicite.util.Grant|init||Info: public connected using curl/7.29.0, timeout = 1800s
2019-11-04 18:12:26,199 INFO [Logon] SIMPLICITE|http://3dfaba09cf40:8080||SESSION|public|Logon|login (direct)||Session utilisateur=public/826F107923A93B11819EB74B5C1FD88D time=0
2019-11-04 18:11:56,056 INFO [com.simplicite.util.Grant] SIMPLICITE|http://3dfaba09cf40:8080||ICORED0001|public|com.simplicite.util.Grant|init||Info: public connected using curl/7.29.0, timeout = 1800s
2019-11-04 18:11:56,047 INFO [Logon] SIMPLICITE|http://3dfaba09cf40:8080||SESSION|public|Logon|login (direct)||Session utilisateur=public/8D22EC534CE59734A4E75C829BA3EEF1 time=0
2019-11-04 18:11:55,232 INFO [com.simplicite.util.Grant] SIMPLICITE|http://3dfaba09cf40:8080||ICORED0001|public|com.simplicite.util.Grant|init||Info: public connected using Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.87 Safari/537.36, timeout = 1800s
2019-11-04 18:11:55,222 INFO [Logon] SIMPLICITE|http://3dfaba09cf40:8080||SESSION|public|Logon|login (direct)||Session utilisateur=public/0DD6A0CEC01831D35537DE2963F240D3 time=0
2019-11-04 18:11:25,936 INFO [com.simplicite.util.Grant] SIMPLICITE|http://3dfaba09cf40:8080||ICORED0001|public|com.simplicite.util.Grant|init||Info: public connected using curl/7.29.0, timeout = 1800s
2019-11-04 18:11:25,926 INFO [Logon] SIMPLICITE|http://3dfaba09cf40:8080||SESSION|public|Logon|login (direct)||Session utilisateur=public/9A3913E01810EAA64B8DBCB0EEC3882D time=0
2019-11-04 18:11:05,747 ERROR [com.simplicite.util.engine.ObjectManager] SIMPLICITE|http://3dfaba09cf40:8080||ECOREDB001|system|com.simplicite.util.engine.ObjectManager|update||Error SQL query: jdbc/simplicite: delete from sites_address where row_id=?
org.postgresql.util.PSQLException: ERROR: update or delete on table "sites_address" violates foreign key constraint "sitesaccesspoint_sitesaddress_acpadr_adr_id_fkc" on table "sitesaccesspoint_sitesaddress"
Detail: Key (row_id)=(66283) is still referenced from table "sitesaccesspoint_sitesaddress".
at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2497)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2233)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:310)
at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:446)
at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:370)
at org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:149)
at org.postgresql.jdbc.PgPreparedStatement.executeUpdate(PgPreparedStatement.java:124)
at org.apache.tomcat.dbcp.dbcp2.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:136)
at org.apache.tomcat.dbcp.dbcp2.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:136)
at com.simplicite.util.engine.DBAccess.update(DBAccess.java:1528)
at com.simplicite.util.engine.DBAccess.update(DBAccess.java:1492)
at com.simplicite.util.engine.ObjectManager.deleteObj(ObjectManager.java:3860)
at com.simplicite.util.engine.ObjectManager.delete(ObjectManager.java:3637)
at com.simplicite.util.ObjectDirect.delete(ObjectDirect.java:543)
at com.simplicite.util.ObjectDB.delete(ObjectDB.java:1511)
at com.simplicite.webapp.tools.JSONServletTool.deleteAll(JSONServletTool.java:1196)
at com.simplicite.webapp.ObjectJson.deleteAll(ObjectJson.java:414)
at com.simplicite.webapp.tools.JSONServletTool.businessObjectService(JSONServletTool.java:547)
at com.simplicite.webapp.servlets.AbstractJSONServlet.service(AbstractJSONServlet.java:68)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at com.simplicite.webapp.filters.AuthMethodFilter.doFilter(AuthMethodFilter.java:115)
at com.simplicite.webapp.filters.AbstractFilter.doFilter(AbstractFilter.java:37)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at com.simplicite.webapp.filters.RewriteFilter.doFilter(RewriteFilter.java:77)
at com.simplicite.webapp.filters.AbstractFilter.doFilter(AbstractFilter.java:37)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:202)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:526)
at com.simplicite.tomcat.valves.APISessionValve.invoke(Unknown Source)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:678)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:408)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:861)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1579)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.base/java.lang.Thread.run(Thread.java:830)
Les pistes que vous devez investiguer dans un cas comme ça sont de regarder s’il n’y aurait pas des contraintes et/ou du code qui implémenterait des règles de suppression conditionnelle de nature à compromettre les suppressions cascade.
Cela dit, pour essayer de comprendre ce qui se passe avant de fouiller dans votre code et vos contraintes vous pouvez aussi procéder pas à pas en faisant manuellement ce que le delete cascade ferait:
supprimer les records de l’objet de relation qui référencent votre record
supprimer le record
Sinon peut être y a-t-il des colonnes “fantômes” sur vos tables qui portent encore des contraintes d’intégrité. Selon la manière dont vous avez importé vos mises à jour successives de paramétrage, ce genre de “fantômes” au niveau physique ne sont pas impossibles (en effet Simplicité ne droppe jamais les tables et les colonnes quand on supprime les objets et les attributs au niveau physique, il les renomme quand il a les infos pour le faire, ce qui n’est pas forcément toujours le cas). Bref, faites un audit de vos colonnes réellement présentes sur vos tables vs les noms de colonnes paramétrés sur les attributs de vos objets métier.
Dans le cas présent des contraintes d’intégrités ont bien été ajoutées car cela avait été exigé par l’équipe projet de l’époque bien que cela soit totalement inutile (voire contre-productif dans le cas de modèles complexes, ex : avec héritages, avec règles de gestion conditionnelles, etc.) comme je l’avais expliqué en long et en large à l’époque sans être compris…
Je le redis ici pour mémoire: avec Simplicité l’intégrité est garantie par le moteur logique, elle est donc inutile au niveau physique sauf si on veut taper directement en mise à jour en base ce qui n’est pas du tout une bonne approche quand on met de l’intelligence (droits, règles de gestion, etc.) au niveau logique.
Mais bon normalement ces contraintes d’intégrité ne devraient pas poser de pb dans ce cas simple.
Bonjour, le problème vient d’être résolu. En effet, on a supprimé les contraintes qui s’étaient générés automatiquement via “Index Proposal”
Je vous remercie de votre aide
Au début du projet les contraintes d’intégrité au niveau physique avaient été demandées, j’avais expliqué que ce n’était pas une bonne idée car au niveau logique on peut faire des paramétrages “avancés” pour lesquels des contraintes d’intégrité physiques seraient un pb (et en général c’est le cas quand on fait des héritages). Les contraintes d’intégrité ne se justifiant que dans les cas où il peut y avoir des accès directs en écriture en base, or ici ce n’est pas le cas…
EN tout cas la génération des contraintes d’intégrité est débrayable via le paramètre système GENERATE_SQL_CONSTRAINTS (qui vaut “no” par défaut).
EDIT:
J’ai testé la demo avec les contraintes d’intégrité sous PostgreSQL, je n’ai pas eu de pb avec le delete cascade sur le cas simple de la suppression d’un produit qui supprime en cascade les commandes effectuées sur ce produit.
Merci beaucoup David pour ces (re)précisions et ce rafraichissement de mémoire… (j’avais enfoui ça profondément)
Pour compléter le propos de David, le positionnement des contraintes au niveau physique avait été imposé par l’équipe de DEV référentiel conduite par A.T. qui posait cette règle comme incontournable pour pouvoir poursuivre le POC (en 2018).
@marwa/gaylord: nous devons désormais choisir entre deux stratégies:
soit on persiste sur la voie des contraintes spécifiées (de manière redondantes) au niveau physique et chaque changement de cardinalité doit être suivi d’une ré-application des “propositions d’index”
soit on suit (enfin) le conseil de l’éditeur et on débraye le mode de report des contraintes sur le physique pour ne plus s’appuyer que sur le standard du socle (contraintes gérées au niveau logique) => comme indiqué par David, c’est aussi simple que de mettre ‘no’ dans le paramètre système (et de nettoyer la bd de ces choses avec les DROP idoines)
=> à capitaliser dans le Wiki projet pour que chaque Product Leader puisse décider de manière éclairée sur son produit
