Objet SELECT sur 3.2

3.2
Objet SELECT sur 3.2
0
Tags: #<Tag:0x00007f4a04143228>

#1

Bonjour,

Je crée un objet SELECT comme j’ai l’habitude sur la 3.0 avec un attribut clé technique qui s’appelle SecESPRIAppId et je fais ma requête (très simple sans jointure pour l’instant) dans le postlaod :

BCSISecESPRI.postLoad = function() {
var sql =“SELECT row_id as sec_espri_app_id,”+
" app_irn,"+
" app_short_name,"+
" app_long_name,"+
" app_desc,"+
" app_domain,"+
" app_sub_domain,"+
" app_type,"+
" app_sub_type,"+
" app_state,"+
" app_scope,"+
" app_it_support,"+
" app_department,"+
" app_dev_ext,"+
" app_dspi_scope,"+
" app_criticality,"+
" app_reactivity,"+
" app_rto,"+
" app_rpo,"+
" app_slr,"+
" app_sla"+
" FROM bcsi_app";
this.setSearchSpec(sql);
};

Quand je fais le test, il fait bien le count (j’ai bien le nombre total d’enregistrements de la recherche selon mes critères) mais à l’affichage j’ai aucune ligne et j’ai cette erreur :

SIMPLICITE|http://server-simplicite-tomcat-ope-compute-bf32a:8080||ECOREDB001|system|com.simplicite.util.engine.ObjectManager|query||Erreur SQL requête: select * from (SELECT row_id as sec_espri_app_id, app_irn, app_short_name, app_long_name, app_desc, app_domain, app_sub_domain, app_type, app_sub_type, app_state, app_scope, app_it_support, app_department, app_dev_ext, app_dspi_scope, app_criticality, app_reactivity, app_rto, app_rpo, app_slr, app_sla FROM bcsi_app) t where (1=1) order by t.row_id asc limit 20
java.sql.SQLSyntaxErrorException: user lacks privilege or object not found: T.ROW_ID

Quand j’essaie la requête qui pose problème toute seule sur la console db :

select * from (SELECT row_id as sec_espri_app_id, app_irn, app_short_name, app_long_name, app_desc, app_domain, app_sub_domain, app_type, app_sub_type, app_state, app_scope, app_it_support, app_department, app_dev_ext, app_dspi_scope, app_criticality, app_reactivity, app_rto, app_rpo, app_slr, app_sla FROM bcsi_app) t where (1=1) order by t.row_id asc limit 20

ça ne marche pas non plus sauf quand je retire le “as sec_espri_app_id” i.e. avec ça :

select * from (SELECT row_id, app_irn, app_short_name, app_long_name, app_desc, app_domain, app_sub_domain, app_type, app_sub_type, app_state, app_scope, app_it_support, app_department, app_dev_ext, app_dspi_scope, app_criticality, app_reactivity, app_rto, app_rpo, app_slr, app_sla FROM bcsi_app) t where (1=1) order by t.row_id asc limit 20

Et là ça marche donc je me dis je vais faire la même modification dans mon objet SELECT :

BCSISecESPRI.postLoad = function() {
var sql =“SELECT row_id,”+
" app_irn,"+
" app_short_name,"+
" app_long_name,"+
" app_desc,"+
" app_domain,"+
" app_sub_domain,"+
" app_type,"+
" app_sub_type,"+
" app_state,"+
" app_scope,"+
" app_it_support,"+
" app_department,"+
" app_dev_ext,"+
" app_dspi_scope,"+
" app_criticality,"+
" app_reactivity,"+
" app_rto,"+
" app_rpo,"+
" app_slr,"+
" app_sla"+
" FROM bcsi_app";
this.setSearchSpec(sql);
};

Et là je tombe sur une Erreur 500.

De mémoire, sur la 3.0 ça marchait bien avec le “as …”.

Est ce qu’il y a eu des changements sur la 3.2 qui expliquent cela?

En vous remerciant.

Zouhair


(François Genestin) #2

oui, comme indiqué dans la release note, nous avons dû corriger un problème de pagination.
En fonction du driver SQL les pages ne garantissaient pas que l’ordre général soit respecté (ex : avec PostgreSQL, si on filtre les users en “français” et on retire tous les “order” sur l’objet = un login peut revenir sur 2 pages car le tri est indéterminé entre 2 pages).

Fixed search: force a final sort on the primary field (to preserve the pagination ordering)

On a donc forcé toute requête avec un order final sur le row_id (après ceux demandés).
il doit plutôt y avoir une régression sur les objets “select” on va regarder.


(François Genestin) #3

Cela fonctionne très bien.

Mais effectivement pour un objet “select”, il est désormais nécessaire d’ajouter en première position dans l’onglet “Attribut d’objet” l’attribut “row_id” sinon vous aurez un problème de mapping entre les champs déclarés sur l’objet et les champs de votre requête.

Le row_id n’est pas ajouté par défaut sur un objet “select”, c’est un mapping explicite à faire entre la requete et les champs.

Par contre cela montre une non compatibilité ascendante des objects “select” 3.0.
On va améliorer ça pour ne pas mettre de “order by t.row_id” par défaut si le “select” spécifique n’a pas la clé primaire de l’objet, mais avec le risque de retomber dans des pb de pagination : charge à l’objet spécifique de faire un tri déterministe inter-page sur ses champs.


(François Genestin) #4

Toutes les version 3.x et 4.0 ont été patchées pour ne plus ordonner les objets ‘select’ sur leur clé primaire.
Et ce, pour garantir une compatibilité ascendante des paramétrages 3.x en 4.0.

On peut toujours explicitement ajouter le champ “row_id” à l’objet “select” et faire un tri dessus via “Attribut d’objet”.
Il faut toujours que l’objet “select” mappe correctement ses champs entre le “select” et les attributs déclarés, sinon cela provoquera toujours des erreurs SQL ou 500 à l’interprétation de l’objet.


#5

Merci pour la correction. Le souci est que mon instance est hébergé en interne et je dois la patché moi-même pour confirmer la correction.
Où est ce que je peux récupérer le patch de correction et le “mode d’emploi” pour l’installer?

En vous remerciant
Zouhair


(François Genestin) #6

Cette question dépasse l’objet de ce post car lié à une prestation spécifique dont nous n’avons aucun contrat de support.

en attendant :

  • il faut utiliser nos environnements Cloud pour les dev pour avoir les mises à jour dès que disponibles
  • ou faire comme j’ai dit en mettant spécifiquement le “row_id” en première position de l’objet select

Ou contacter David en privé dans le cadre d’un support spécifique.


(David AZOULAY) #7

Merci de me contacter par mail pour qu’on voit comment appliquer la mise à jour sur ton environnement temporaire hébergé en interne (de mémoire on avait pas pris le temps d’installer Apache Ant or la procédure d’upgrade a besoin de cet outil).


(Robin OPRASEUTH) #8

Bonjour,

Je viens de mettre à jour mon appli de la version 3.0 vers la 3.2 M06 et je rencontre le même souci avec mes objets SELECT.
J’ai essayé d’ajouter l’attribut row_id dans mon objet mais cela ne résoud pas le problème.

Voici l’erreur que j’ai :

févr. 09, 2018 10:35:06 AM org.apache.catalina.core.StandardWrapperValve invoke
GRAVE: Servlet.service() for servlet [jsp] in context with path [/pepsmoa] threw exception [An exception occurred processing JSP page [/jsp/ALL_list.jsp] at line [41]

38: String inst = params.getParameter(“inst”, “the_”+obj);
39: ObjectDB o = theGrant.getObject(inst, obj);
40:
41: String content = o.displayList(theList, params, theNav, null);
42: if (content.startsWith(“REDIRECT:”))
43: {
44: response.sendRedirect(content.substring(9));

Stacktrace:] with root cause
java.lang.ArrayIndexOutOfBoundsException: 2
at com.simplicite.util.ObjectCore.setValues(ObjectCore.java:3712)
at com.simplicite.util.ObjectCore.setValues(ObjectCore.java:3660)
at com.simplicite.webapp.ObjectList.buildTrLine(ObjectList.java:2186)
at com.simplicite.webapp.ObjectList.display(ObjectList.java:706)
at com.simplicite.webapp.ObjectList.display(ObjectList.java:61)
at com.simplicite.webapp.ObjectList.display(ObjectList.java:56)
at com.simplicite.util.ObjectDB.displayList(ObjectDB.java:2008)
at org.apache.jsp.jsp.ALL_005flist_jsp._jspService(ALL_005flist_jsp.java:192)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:443)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:386)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:330)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
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:52)
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:184)
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:199)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:621)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81)
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:650)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:342)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:803)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:790)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1459)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)

Y a-t-il une autre solution à ce problème?


(David AZOULAY) #9

Sans le détail de votre paramétrage c’est pas facile d’investiguer. Merci de nous fournir plus d’informations


(Robin OPRASEUTH) #10

J’ai un objet SELECT simple sans héritage, avec 13 attributs d’objets.
La requête est construite dans le postload et retourne 13 champs.

J’ai tenté d’ajouter le champ row_id dans mon objet SELECT mais j’ai la même erreur.
J’ai aussi remplacé la requête du postload par une autre qui ne retourne qu’un seul champ, le row_id, et j’ai la même erreur ArrayIndexOutOfBoundsException.


(David AZOULAY) #11

Il y a un exemple basique d’objet select dans le module Examples disponible ici: https://www.simplicite.io/resources/modules/examples-3.1.xml

Ca donne ça:

Pour la requête (cf. la search spec de l’objet):

select
	val,
	label,
	description
from exselect
where val < 30
order by val

La table exselect (cf. le commentaire de l’objet) ayant été créée manuellement comme suit:

create table exselect (val integer, label varchar(100), description longvarchar);
insert into exselect values (10, 'Label 1', 'Description 1');
insert into exselect values (20, 'Label 2', 'Description 2');
insert into exselect values (30, 'Label 3', 'Description 3');

(Robin OPRASEUTH) #12

Bonjour,

Merci pour l’exemple.
Il y avait une erreur de paramétrage dans mon objet. Le champ timestamp était à “oui”, qui n’avait pas lieu d’être pour un objet SELECT.
Je l’ai repassé à “non” et ça fonctionne.


(David AZOULAY) #13

Oui c’est le piège classique des objets select.

En 4.0 le socle remonte des warnings dans les post sociaux pour ce qu’il considère comme des paramétrages “douteux” il faudrait clairement mettre ce cas dans la liste des warnings…