DROP de table ORACLE si et seulement si elle existe

Imaginons que vous souhaitez créer une table par script SQL sur Oracle 11 (par exemple la table TEST).

Mais vous ne savez pas si elle existe déjà ou non.

Et surtout vous ne voulez aucune erreur (ni à la création, ni à la destruction) !

Vous pouvez alors utiliser un script de configuration comme suit :

DECLARE
  t_count INTEGER;
  v_sql VARCHAR2(1000) := 'DROP TABLE  "TEST"  CASCADE CONSTRAINTS';
BEGIN
  SELECT COUNT(*)
    INTO t_count
    FROM user_tables
   WHERE table_name = 'TEST';

  IF t_count > 0 THEN
    EXECUTE IMMEDIATE v_sql;
  END IF;
END;


Qui effacera la table si et seulement si elle existe préalablement.

Ensuite le script de création pourra se dérouler normalement, et sans erreurs.

Comparateurs en JSF

JSF et ses pages xhtml ne doivent bien-sûr pas contenir les caractères réservés de xml dans les valeurs ou tests.

Par exemple : 

"&" deviendra "and" en test logique 

"<" deviendra "lt"

">" deviendra "gt"

Extraire une variable dans JMeter et la persister dans un fichier CSV

Comment faire lorsqu'on extrait une variable en utilisant l'extracteur d'expression régulière de JMeter, et que l'on souhaite la conserver dans un fichier ?

Pour écrire dans un fichier ( CSV par exemple ) un ou des variables lors de tests JMeter, rien de plus simple. 

Il suffit de rajouter après la ou les extractions de variables un postprocesseur de type BeanShell. 

Et renseigner la partie script avec du code de type :

nomVariableAEnregistrer = vars.get("variable");

nomFichier = vars.get("fichierExtrait");

log.info("le log de JMeter à renseigner facultativement qui se trouvera dans le fichier jmeter.log");

fos = new FileOutputStream( nomFichier, true );//le booléen sert à indiquer si le fichier doit être concaténé ( vrai ) ou écrasé ( faux )

ps = new PrintStream ( fos );

this.interpreter.setOut( ps );

print( nomVariableAEnregistrer + "," );

fos.close();

/* Le code précédent récupère les variables nécessaires qui doivent déjà être déclarées. Il ouvre un flux vers le fichier de sortie et le créé au besoin. Écrit la variable. Concatène une virgule. Puis ferme le flux vers le fichier. */

J'ai utilisé ceci pour extraire vers un fichier CSV des numéros de contrats créés lors de tests scriptés JMeter de montée en charge. 

Les numéros de contrat ainsi récupérés pouvant servir à d'autres types de tests. 

Champ booléen en oracle

Il n'y a pas de type booléen de défini par défaut en table, en base de données Oracle. Certaines bases de données permettent l'usage de boolean, ou à défaut de bit ou tinyint. Oracle ne le permet pas. 

La meilleur solution consommant le moins de place est un char de un byte ou octet avec deux valeurs permises (O,N ou Y,N ou 0,1). 

Par exemple :

CREATE TABLE BOOLEEN (bool varchar2 (1) check (bool in ('O','N'));

Ou encore :

ALTER TABLE SPI ADD ( COLONNE1 VARCHAR2(1) DEFAULT 'O' NOT NULL CHECK ( COLONNE1 IN ('O','N')));

Annotation spring cacheable

L'annotation Spring @Cacheable existe depuis la version 3.1 de SPRING. 

Cette annotation permet de mettre en cache des appels de méthodes. 

Il va sans dire que cela  peut améliorer la performance de l'application mais il faut l'utiliser à bon escient. 

Si la méthode est certaine de retourner toujours le même résultat pour des données en entrée identiques ( arguments) alors il peut être de bon ton de la déclarer Cacheable. 

Si ce n'est pas le cas il vaut mieux éviter de mettre en cache le résultat de l'appel de la méthode. Par exemple si au cours du temps pour les mêmes arguments la valeur de retour de la méthode varie ou évolue. 

D'autres annotations d'intérêt pour le cache sont : @CachePut qui force la mise à jour du cache et sers à initialiser le cache plutôt qu'à optimiser les appels. 

Pour faire simple il permet de populer le cache avec une exécution de méthode qui servira ensuite dans l'optimisation des appels par SPRING. Il ne faut pas utiliser @CachePut et @Cacheable sur la même méthode. 

@CacheEvict lui aussi met à jour le cache mais en effaçant des données. Il supprime possiblement du cache toutes les entrées visées. La méthode dont il est l'annotation peut être de type void car elle n'est qu'un déclencheur d'action. 

Pour combiner plusieurs annotations : l'annotation à utiliser est @Caching. 

La bible de ces annotations se trouve ici : 

Http://docs.spring.io/spring/docs/3.1.x/spring-framework-reference/html/cache.html

CreateProcess error=87

Aujourd'hui j'ai eu une erreur Éclipse lors du lancement d'un test JUnit 4. 

"Cannot run program ... Error=87"

Il s'agit d'un problème connu sous Windows car sa ligne de commande n'accepte pas les commandes d'une longueure supérieur à 8191 caractères.

Dans un projet avec, par exemple, de nombreux imports, d'un répo MAVEN, d'autres projets, etc. cela pose un problème. 

Il y a plusieurs solutions mais le but est de réduire la taille du CLASSPATH passé en paramètre à la ligne de commande par éclipse. 

Pour mon cas j'ai préféré laisser la main à MAVEN pour lancer mes tests JUnit, histoire de ne pas modifier la configuration de mon poste de travail. 

Désavantages : sans lancer comme un run JUnit sous éclipse, on a pas le droit à la jolie interface graphique du plugin JUnit éclipse. De plus par défaut tous les tests du projet sont déroulés. 

Avantage : pas de souci de longueur de ligne de commande sous Windows. 

CD {chemin répertoire projet}

mvn test

Réalisable aussi sous éclipse : run as MAVEN build. 

Bien sur ceci pour un projet MAVEN. 

Protéger une apostrophe en SQL

Lorsqu'on souhaite saisir une apostrophe dans une chaîne de caractères SQL il suffit de la doubler : " '' " au lieu de " ' ". 

Par exemple :

INSERT INTO LIBELLES (ID,LABEL) VALUES (1,"un texte avec l''apostrophe doublé");