Bdd oracle + Simplicite 4.0 => Les modules sont créés mais non visibles.
java.sql.SQLException: operation not allowed: Unsupported syntax for refreshRow()
Peut on avoir plus de précisions sur le problème rencontré (copies d’écran, logs, etc…) car on a testé sur une instance vierge Oracle et on arrive bien a créer un module puis à le charger via XML, le résultat nous semble OK
Bref on ne comprend pas le point…
Création d’une instance vierge sur la version 4.0 avec base de données Oracle via un sim add
tu peux reproduire ici via Administration > Module
http:///xxxxxx.simplicite.io/ui/
dxxxx/ dxxxxxx
Cette copie d’écran partielle ne nous suffira clairement pas à comprendre le problème car par exemple sur notre instance Oracle la liste des modules est correcte:
Il va falloir nous donner plus d’informations…
tu peux reproduire ici via Administration > Module
http://xxxxxx.simplicite.io/ui/
dxxxxx / dxxxxxxxx
Il y a aussi des erreurs SQL
2017-12-18 17:34:34,992 ERROR [com.simplicite.util.engine.ObjectManager] SIMPLICITE|http://partenor.simplicite.io:10308||ECOREDB001|system|com.simplicite.util.engine.ObjectManager|query||Error SQL query: jdbc/simplicite: select t.row_id, t.pcf_process_id, t_pcf_process_id.pcs_name, t.pcf_serial, t.pcf_start_dt, t.pcf_end_dt, t.pcf_duration, t.pcf_status, t.pcf_deadline_dt, t.pcf_object, t.pcf_acf_id, t_pcf_acf_id.acf_pcf_id, t_acf_pcf_id.pcf_serial, t_pcf_acf_id.acf_serial, t_acf_pcf_id.pcf_process_id, t_pcf_acf_id_acf_pcf_id_pcf_process_id.pcs_name, t.pcf_owner_id, t_pcf_owner_id.usr_login, t_pcf_owner_id.usr_last_name, t_pcf_owner_id.usr_first_name, t_pcf_owner_id.usr_email, t_pcf_owner_id.usr_work_num, t.created_dt, t.created_by, t.updated_dt, t.updated_by from bpm_process_file t inner join bpm_process t_pcf_process_id on (t.pcf_process_id=t_pcf_process_id.row_id) left outer join bpm_activity_file t_pcf_acf_id on (t.pcf_acf_id=t_pcf_acf_id.row_id) left outer join bpm_process_file t_acf_pcf_id on (t_pcf_acf_id.acf_pcf_id=t_acf_pcf_id.row_id) left outer join bpm_process t_pcf_acf_id_acf_pcf_id_pcf_process_id on (t_acf_pcf_id.pcf_process_id=t_pcf_acf_id_acf_pcf_id_pcf_process_id.row_id) left outer join m_user t_pcf_owner_id on (t.pcf_owner_id=t_pcf_owner_id.row_id) where (t.pcf_object like ? ) and (1=1) order by t_pcf_process_id.pcs_name asc, t.pcf_serial asc, t.row_id asc
java.sql.SQLSyntaxErrorException: ORA-00972: identifier is too long
et lors d’import de module des erreurs de type
ALTER TABLE tutu ADD tut_nb longinteger
java.sql.SQLSyntaxErrorException: ORA-00902: invalid datatype
OK sur une instance nouvellement créée on constate effectivement le pb (l’autre instance avait été créé il y a quelques semaines et mise à jour quotidiennement depuis). Bizarre. On regarde ce qui aurait pu régresser depuis dans le cas de Oracle…
super merci beaucoup
Visiblement Oracle ne supporte pas 2 fois le même nom de colonne dans une requête:
select sys_code, sys_code from m_system
Error: operation not allowed: Unsupported syntax for refreshRow()
Ca explique donc le pb sur le module qui utilise le updated_dt 2 fois car un de ses attributs mappe dessus. Je ne sais pas de quand ça date mais, clairement, c’est pas un bon pattern pour Oracle…
L’autre erreur concernant le type longinteger c’est bizarre car ce type existe en Oracle 10+ mais sur ce site il est dit que le type bigint MySQL “correspond” à number(38)…
cf. https://docs.oracle.com/cd/E19501-01/819-3659/gcmaz/
Je laisse François répondre sur ce point
-
Le pb d’alias de table “long” est normalement corrigé. J’avais ajouté un hash qui tronque et indexe à la longueur souhaitée via un param système ORACLE_ALIAS_LENGTH / voir vieux post
-
Les int et double sont passés en taille “max” dans toutes les bases pour gérer les bigint / bigdecimal dans les sommes et les TC. Faut remplacer longinteger avec ce qui est le plus grand entier dans : https://docs.oracle.com/cd/B28359_01/server.111/b28286/sql_elements001.htm#SQLRF0021
-
refreshRow : le moteur Simplicité ne fait aucun appel à cette méthode du driver Oracle
on n’avait jamais vu ce problème qui va bien être galère à corriger et ralentir les perfs Oracle puisqu’on va réindexer toutes les colonnes à chercher pour gérer l’unicité dans le “select”, puis redistribuer dans l’objet les champs en double.
Mon avis vous l’avez déjà eu : Oracle est une base du passé (qui continue de limiter les noms à 30 char, ne pas respecter le SQL99 sur pas mal de points…) et pose désormais plus de problèmes qu’elle n’en résout. En gros le moteur SQL de Simplicité n’a plus rien de générique quand on parle d’Oracle et il faut indiquer à votre client qu’on devra prévoir surcout de maintenance sur le long terme, que les perfs seront différentes des autres DB puisque overhead de traitements spécifiques pour faire plaisir à un vieux bouzin.
Donc en clair mon avis est de passer à autre chose.
-
longinteger remplacé par number(size) donc fonction de la taille du champ, on peut donc aller jusqu’à 38
à livrer -
sur la longueur des table-alias limitée à 30 sur les anciens Oracle, il faut essayer avec ORACLE_ALIAS_LENGTH=30 ou 25 (normalement la valeur par défaut est 30)
sinon il y a un bug dans ObjectDB.getTableAlias pour Oracle que je n’ai pas en local pour debugger -
sur le pb refreshRow, il faut avoir un support Oracle que nous n’avons pas, je n’ai rien trouvé sur le net qui date d’après 2004
-
select row_id, null, null from m_system
plante aussi et il n’y a pas 2 fois la même colonne
a-t-on vérifié la version du driver vs oracle vs jdk ?
sur le point 2 je vais retravailler le convertisseur de scripts SQL pour mettre du number(x) au lieu de longinteger
sur le point 3 je précise que si on aliase les colonnes en doubles il n’y a pas de pb:
OK:
select sys_code, sys_code as sys_code_bis from m_system
KO:
select sys_code, sys_code from m_system
Toujours sur le point 3, avant de se lancer dans une refonte de la mécanique de l’object manager avec tous les reisques que cela induit, je propose déjà de refactorer en champs calculé les colonnes qui mappent sur created_*/updated_*. J’ai vérifié il n’y en a que 3 au niveau du socle:
- un sur module
- un sur supervision des imports
- un sur ALM ticket doc
Après investigation il semble que c’est juste un pb lié au driver JDBC !
Avec un driver JDBC plus ancien ça remarche…
Bref, comme toujours avec Oracle, il faut faire bien attention à choisir le driver JDBC qui est le plus “compatible” avec son serveur Oracle au risque d’avoir des problèmes incompréhensibles.
Je vais changer donc le driver sur le SIM partenor.simplicite.io en espérant que celui là n’induira pas d’autres problèmes
Chez votre client vous devrez donc faire très attention au driver que vous installerez
Merci d’avoir traité ce sujet rapidement.
Sébastien
Il faut toujours prendre le driver contenu dans sa distribution et dans le bon JDK.
http://www.oracle.com/technetwork/topics/jdbc-faq-090281.html
Bonjour,
Quand allez-vous pousser la mise à jour pour les “number” sur la branche “release” ?
Cordialement,
Est-ce que tu as validé sur votre SIM que tout est OK ?
Si oui on poussera dans la branche release ce soir