Difference between revisions of "FR/Documentation/HSQLDB Guide/ChangeLog1.7.2"

From Apache OpenOffice Wiki
Jump to: navigation, search
(Métadonnées de base de données)
m (Persistance)
Line 308: Line 308:
 
<nowiki>SET WRITE_DELAY {TRUE | FALSE}</nowiki> est interprété comme une synchronisation toutes les 60 secondes ou chaque seconde. SET WRITE_DELAY <n> ou n est un entier est interprété comme une synchronisation toutes les n secondes. La valeur par défaut actuelle est 60 secondes qui semble fournir le bon compromis. Dans des conditions de test intensives (INSERT/DELETE/UPDATE), l'impact sur les performances de SET WRITE_DELAY 1 est probablement d'environ 15% par rapport à celui de SET WRITE_DELAY 300.
 
<nowiki>SET WRITE_DELAY {TRUE | FALSE}</nowiki> est interprété comme une synchronisation toutes les 60 secondes ou chaque seconde. SET WRITE_DELAY <n> ou n est un entier est interprété comme une synchronisation toutes les n secondes. La valeur par défaut actuelle est 60 secondes qui semble fournir le bon compromis. Dans des conditions de test intensives (INSERT/DELETE/UPDATE), l'impact sur les performances de SET WRITE_DELAY 1 est probablement d'environ 15% par rapport à celui de SET WRITE_DELAY 300.
  
 +
La récupération d'un crash a été modifiée de sorte que toute ligne dans le fichier *.log incorrectement écrite (et qui donc provoque une erreur) termine le processus "refaire" (redo). Un message est envoyé à l'utilisateur au lieu de l'arrêt pur et simple de l'opération du moteur.
  
Crash recovery has been modified so that any line in the *.log file that is not properly written (and causes an error) ends the redo process. A message is reported to the user, instead of stopping engine operation.
+
=== Accès NIO des fichiers *.data ===
 
+
 
+
<nowiki>----------------</nowiki>
+
 
+
 
+
NIO ACCESS FOR *.data FILES
+
  
  

Revision as of 13:10, 24 March 2009

HSQLDB 1.7.2 Historique des changements

(HSQLDB 1.7.2 CHANGE LOG)

Le développement de la version 1.7.2 a commencé fin 2002 avec pour objectif de sortir une nouvelle version dans les six mois. Plusieurs versions alpha, jusqu'à ALPHA_M, sont sorties dans les trois premiers mois et contenaient la plupart des améliorations projetées. Toutefois, quand le code nouvellement écrit pour les tables systèmes a été introduit, beaucoup de changements ont du être faits au code interne pour se conformer aux nécessités de compte-rendus. Ce fut suivi depuis environ Avril 2003 avec les efforts pour séparer les compilations de requête de leur exécution. D'autres développements pour permettre les bases de données multiples, meilleurs traitements des requêtes, mots clés SQL plus avancés, etc. prirent place simultanément, aboutissants à une portée étendue pour la version 1.7.2, d'ajouts et de ré-écritures de plusieurs classes de clefs. La version alpha suivante fut publiée en Septembre, suivie du suffixe six (followed by a further six ?) jusqu'à ce que la première version candidate devienne disponible fin 2003. Depuis lors, tous les efforts ont été concentrés sur les réparations de bogues et incompatibilités, avec la sortie de 7 versions candidates supplémentaires.

Au final, les fonctionnalités de la 1.7.2 apportent des changements majeurs au moteur de la base de données. Les applications existantes fonctionnant avec les versions précédentes nécessitent des modifications pour utiliser la nouvelle version. Les changements sont listés ici et dans le reste de la documentation.

J'aimerai remercier tous les développeurs, testeurs et utilisateurs qui ont contribué à ce travail.

Juin 2004

Fred Toussi

Maintainer, HSQLDB Project

http://hsqldb.sourceforge.net


Améliorations SQL et changements

DDL (Langage de définition des données)

De nouvelles restrictions ont été imposées :

Les noms de contrainte doivent être unique dans chaque base de données (de même avec les noms d'index). Les valeurs Taille / Précision / Echelle pour plusieurs types ne sont maintenant plus permises. Les types permis sont : CHAR(n), VARCHAR(n), DOUBLE(n), DECIMAL(n,m)

Dans la spécification de valeur par défaut de colonne, des fonctions comme CURRENT_TIME, CURRENT_DATA, etc. ne doivent pas être encadrées d'apostrophe. Une nouvelle fonction CURRENT_USER peut également être utilisée.

Les mots-clés SQL ne sont pas permis comme noms de table ou de colonne à moins qu'ils soient entre guillemets.

VIEW

Les définitions de vues possèdent maintenant une liste de noms de colonnes :

CREATE VIEW <NomDeLaVue> [(<NomDeColonne>, ...)] AS SELECT ....

Les commandes ALTER TABLE prennent en compte les vues qui référencent la table et empêchent les changements illégaux.

CHECK

Prise en charge des contraintes CHECK qui s'appliquent seulement à la ligne modifiée/insérée. Elles peuvent être ajoutées par la commande ALTER TABLE ADD CHECK()ou dans la définition de table.

Traitement des requêtes

Le traitement des requêtes a été grandement amélioré dans cette version et une meilleure conformité au standard SQL a été atteinte. Les implications majeures des récent changements sont comme suit :

D'abord les colonnes dans les sous-requêtes en corrélation sont résolues indépendamment. S'il y a une colonne irrésolue, alors le contexte environnant est utilisé pour la résoudre. Ceci est l'opposé de l'ordre de résolution précédemment requit par le moteur.

Quelques ambiguïtés et erreurs dans les clauses ORDER BY sont maintenant réglées (caught).

Les requêtes UNION et autres (UNION and other set queries) acceptent seulement une clause ORDER BY à la fin. Dans cette clause, les noms d'index ou de colonnes dans la première sélection sont permis comme spécification de tri. Par exemple :

SELECT .. UNION SELECT .. ORDER BY 1 DESC, 5, 3

L'implémentation des opérations de choix UNION, EXCEPT et INTERSECT a été ré-écrite pour se conformer aux standards SQL.

Quand de multiples opérations de choix sont présentes dans une requête, elles sont maintenant évaluées de la gauche vers la droite, avec la priorité de INTERSECT sur le reste.

Il est maintenant possible d'utiliser les parenthèses autour de multiples (ou simples) déclarations SELECT avec les opérations de choix pour changer l'ordre de l'évaluation. Par exemple :

((SELECT * FROM A EXCEPT SELECT * FROM B) INTERSECT SELECT * FROM D UNION SELECT * FROM E)

La règle ci dessus s'applique à tous les cas ou un SELECT peut être utilisé excepté pour une simple valeur select à l'intérieur d'un autre select. Exemple :

SELECT a, b, SELECT UneSimpleValeur FROM UneAutreTable WHERE ..., FROM UneTable JOIN ...

Améliorations pour UPDATE et INSERT

Certains types de UPDATES et d'INSERTS qui échouaient préalablement à cause des applications de couverture (blanket application) de contraintes UNIQUE fonctionnent maintenant.

Les exemples incluent UPDATE ... SET col = col + 1 ou col est une colonne identifiant ou INSERT une ligne auto-référentielle (self referencing row) sous des contraintes de clés externes

AGGREGATES, GROUP BY, HAVING

Les agrégations DISTINCT sont maintenant supportées.

Les agrégations sur tous les types de colonnes numériques sont maintenant supportées. Les expressions sont permises comme des paramètres de fonction d'agrégation.

La fonction SUM (somme) renvoie BIGINT pour les colonnes TINYINT, SMALLINT et INTEGER. Elle renvoie DECIMAL pour les colonnes BIGINT (échelle 0). La somme d'une colonne DECIMAL a la même échelle que la colonne.

AVG (average = moyenne) renvoie le même type que la colonne ou l'expression dans ses arguments.

Les agrégations avec GROUP BY ne renvoient aucune ligne si la table est vide.

Fully enforced GROUP BY rules including support for HAVING conditions

Jointures

La ré-écriture (extensive ?) du traitement de jointure abolit le besoin d'index sur toute colonne jointe.

Les problèmes avec les jointures externes et internes (OUTER et INNER) qui renvoyaient des résultats faux ont été réparés et les résultats sont maintenant corrects dans tous les cas.

Quand deux tables sont jointes, les lignes résultantes de la jointure de valeurs nulles dans les colonnes jointes ne sont plus retournées.

La plupart des expressions sont prises en charge dans les conditions de jointure (JOIN <table> ON ....).

Les conditions de jointure externes peuvent maintenant inclure la plupart des opérateurs de comparaison, aussi bien que les opérateurs logiques. Par exemple :

LEFT OUTER JOIN UneTable ON a=b AND c>d OR a=2 ...

Les références illégales aux tables devant (forward ?) ne sont plus maintenant permises dans les conditions de jointure.


Beaucoup d'autres petites améliorations et réparations, dont :

NULLS

Prise en charge de lignes multiples avec des champs NULL sous des contraintes unique.

Exclusion des valeurs NULL des résultats de requêtes avec des conditions de plages de valeurs.

Clé externe

FOREIGN KEY

Prise en charge complète pour les actions déclenchées, incluant les clés externes référençant la même table.

FOREIGN KEY ... ON UPDATE { CASCADE | SET NULL | SET DEFAULT } ON DELETE { CASCADE | SET NULL | SET DEFAULT }

Le traitement strict des nécessités de contrainte de clé externe est maintenant renforcé. Une déclaration de clé externe requiert une contrainte unique pour être créée sur les colonnes de la table référencée. Ceci s'applique à la fois aux anciennes et aux nouvelles bases de données. Les duplications de clés externes (avec exactement le même jeu de colonnes) ne sont maintenant plus permises

SEQUENCE

Prise en charge des séquences. Les colonnes d'identité sont maintenant des colonnes de clés primaire auto-incrémentées qui peuvent être définies comme INTEGER ou BIGINT comme suit :

GENERATED BY DEFAULT AS IDENTITY (START WITH <n>, INCREMENT BY <m>)

Les objets de séquence nommés peuvent être définis avec :

CREATE SEQUENCE <NomDeSéquence> [AS {INTEGER | BIGINT}] [START WITH <ValeurDeDépart>] [INCREMENT BY <ValeurDIncrément>];

Et la prochaine valeur peut être récupérée avec l'expression suivante dans les requêtes SELECT, INSERT et UPDATE :

NEXT VALUE FOR <sequencename>

Fonctions SQL

Prise en charge ajoutée pour nombre de fonctions style SQL (Added support for a range of SQL style functions) :

CASE .. WHEN .. THEN .. [WHEN .. THEN ..] ELSE .. END


CASE WHEN .. THEN .. [WHEN .. THEN ..] ELSE ... END


NULLIF(.. , ..)


SUBSTRING(.. FROM .. FOR ..)


POSITION(.. IN ..)


TRIM( {LEADING | TRAILING .. } FROM ..)


EXTRACT({DAY | TIME |..} FROM ..)


COALESCE(.. , ..)

TRIGGER

Il est maintenant possible d'exécuter des déclencheurs dans la fenêtre (thread) d'exécution principale. Ceci permet l'usage de déclencheurs qui n'étaient pas possibles avant, spécialement pour la vérification et la modification de valeurs insérées.

DATETIME

Réparation des problèmes de normalisation pour TIMESTAMPS, TIME et DATE.

Autres

Les listes de valeurs IN peuvent maintenant contenir des valeurs de colonnes ou d'expressions. Voir le fichier TestSelfQueries.txt pour un exemple

Le prédicat LIKE a été débogué et optimisé quand c'était possible.

Améliorations JDBC

Support JDBC pour les points de sauvegarde.

Prise en charge des fichier exécutables JDBC batch à résultats multiples. Les deux modes batch Statement et PreparedStatement sont supportés.

Prise en charge de SSL pour opération en mode Serveur.

Après l'appel de Statement.setMaxRows(int), la restriction du nombre maximum de lignes ne s'applique plus aux jeux de lignes retournées (result sets returned) et utilisés en interne. (changements dans la 1_7_2_5)

Propriété de la connexion

Une nouvelle propriété, ifexists={true|false} peut être définie pour les connexions. Elle est effective seulement pour les connexions aus bases de données in-process. La valeur par défaut est false et correspond au comportement courant.

Si cette propriété est définie à true, la connexion est ouverte seulement si les fichiers de la base de données ont déjà été créés. Autrement il n'est pas créé de nouvelle base de données et la connexion attendue échouera. Exemple :

jdbc:hsqldb:hsql:file:mydb;ifexists=true

Le but de cette propriété est de réduire les problèmes résultants d'URL's incorrects qui sont traduites en fichiers d'une nouvelle base de données non désirée. Il est recommandé d'utiliser cette propriété à des fins de dépannage.

Les propriétés de la base de données peuvent être spécifiées pour la première connexion à une base de données file: ou mem: . Ceci permet à des propriétés telles que enforce_strict_size d'être spécifiées pour des bases de données mem: , ou pour une nouvelle base de données file: .

jdbc:hsqldb:hsql:mem:test;sql.enforce_strict_size=true

Déclarations préparées

(PREPARED STATEMENTS)

Prise en charge de vraies déclarations préparées - véritable accélération. Ce qui a introduit les changements suivants depuis les versions précédentes.

Les commandes execute, executeUpdate et executeQuery (toutes trois chaînes SQL) ne sont plus supportées pour PreparedStatements conformément aux spécifications JDBC. Utilisez une déclaration ordinaire pour appeler ces méthodes.

Le SQL pour chaque appel à la méthode de connexion PreparedStatement() consiste en une simple requête SQL. Pour des déclarations multiples utilisez soit les objets multiples PreparedStatement ou une déclaration d'objet ordinaire.

Réparations de bogues assurant que date / heure, objets Java et valeurs binaires stockés dans les bases de données in-process par les déclarations préparées ne seront pas altérés si l'objet est modifié en dehors du moteur.

Prise en charge complète pour ResultSetMetaData

Prise en charge complète pour ParameterMetaData

Prise en charge pour les méthodes CLOB dans un ResultSet

Transactions via un serveur Web

Prise en charge homogène pour les transactions via les protocoles HSQL et HTTP (Serveur web et Servlet)

Autres améliorations

Vitesse

Optimisation de la vitesse des jointures avec les vues et les sous-requêtes, en utilisant des index pour optimiser la performance de la jointure.

Utilisation de l'index améliorée pour les jointures multiples.

Améliorations de la vitesse approfondie dans tous les modes consignés (logged).

Les opérations INSERT et UPDATE sont plus rapides de 5 à 20 % dans les tables mémoire, plus lentes dans les tables en cache.

Accélération générale des opérations de tables en cache due à une meilleure gestion du cache mémoire.

Conditionnement de la base de données et modes

Deux nouvelles options pour les bases de données : files_readonly et files_in_jar ont été ajoutées :

File read-only

Si la propriété hsqldb.files_readonly=true est définie dans le fichier .properties de la base de données, aucun changement n'est écrit dans le fichier. Par défaut, les tables mémoire peuvent être lues/écrites mais les tables en cache et texte sont traitées en lecture seule.

Les fichiers dans la jar (archive Java)

Cette option permet aux fichiers de la base de données d'être distribués dans l'application jar. La contribution originale a été modifiée afin qu'une URL spéciale soit utilisée pour ce mode sous la forme :

jdbc:hsqldb:res:<path in jar>

Le type d'URL 'res' signifie que le chemin qui suit est un chemin dans la JAR. Le chemin doit être intégralement en minuscules et commencer par un slash ("/")

La base de données peut être readonly ou files_readonly, selon la valeur définie dans le fichier .properties.

Type de données 'OTHER'

Changement dans la manipulation des colonnes OTHER. Il n'est plus besoin que les classes pour les objets stockés dans les colonnes OTHER soient disponibles sur le chemin d'un moteur HSQLDB exécuté comme serveur. Les classes doivent être disponibles sur le chemin JDBC du client.

Bases de données IN-MEMORY et SERVER multiples

Prise en charge de bases de données multiple en mémoire seule dans la même JVM (machine virtuelle Java).

Prise en charge de plusieurs serveurs simultanément sur différents ports, de plusieurs connexions internes et de plusieurs bases de données à l'intérieur de la même JVM.

Chaque serveur ou serveur web HSQLDB peut maintenant servir jusqu'à 10 bases de données différentes.

Les méthodes server.properties et webserver.properties pour définir les bases de données ont changé. Les propriétés suivantes doivent être utilisées :

server.database.0 path_of_the_first_database

server.dbname.0 alias_for_the_first_database

Jusqu'à 10 bases de données peuvent être définies mais l'indexation doit démarrer de zéro. Ceci s'applique aussi aux arguments de la ligne de commande pour Server et WebServer.

Les URL's de connexion aux serveurs doivent finir par l'alias de la base de données. Par exemple, pour se connecter au protocole serveur HSQL sur l'hôte local utilisez :

jdbc:hsqldb:hsql://localhost/alias_pour_la_base

Où alias_pour_la_base est la même chaîne de caractères que définit dans server.properties comme server.dbname.n

Si ce n'est pas explicitement défini, la valeur par défaut pour server.dbname.0 est "" (chaîne vide), ainsi l'ancien type d'URL continue de fonctionner.

Les bases de données multiples en mémoire seule sont supportées par l'usage de :

jdbc:hsqldb:mem:alias_de_la_première_base

jdbc:hsqldb:mem:alias_de_la_seconde_base

Exemples: jdbc:hsqldb:mem:db1 jdbc:hsqldb:mem:maBase

Le type de connexion, 'file:', peut être utilisé pour les connexions aux bases de données fichier. Exemple ci-dessous :

jdbc:hsqldb:file:maBase;ifexists=true

L'URL de connexion à un serveur Servlet HTTP doit finir par un slash ("/"). les Servlet ne servent qu'un seule base de données.

jdbc:hsqldb:hsql://localhost:8080/servlet/HsqlServlet/

Métadonnées de base de données

Les prises en charge de table système et de java.sql.DatabaseMetadate ont été "overhauled" ??? . (System table support and java.sql.DatabaseMetadate have been overhauled.)

Entrez SELECT * FROM SYSTEM_TABLES pour voir la liste complète.

Tables texte

Amélioration de la prise en main de la table texte et report d'erreurs dans les fichiers CSV (source)

L'encodage du fichier source des tables texte peut maintenant être défini. UTF-8 et d'autres encodages peuvent être utilisés.

Utilisation de la mémoire et groupage d'objets

Un objet Groupe a été incorporé (An Object pool has been incorporated). Ceci réduit l'utilisation de la mémoire à divers degrés, dépendant du contenu des tables de la base de données, et accélère cette dernière dans la plupart des cas. Actuellement la taille du groupe est codée (hard-coded) mais elle pourra être ajustée par l'utilisateur dans une version future.

Persistance

CHECKPOINT DEFRAG

Défragmente le fichier *.data sans fermer la base de données.

SET SCRIPTFORMAT {TEXT | BINARY | COMPRESSED }

Change le format du fichier *.script et accomplit un checkpoint.

Le script de base de données peut être stocké aux formats binaire ou binaire compressé, résultant en un taille plus petite et un chargement plus rapide.

Le fichier *.script contient maintenant seulement le DDL (Langage de définition des données) et les données écrites au CHECKPOINT ou au SHUTDOWN. Parallèlement le format COMPRESSED a le bénéfice de cacher le DDL et le mot de passe administrateur.

Le fichier *.log contient maintenant les déclarations exécutées depuis le dernier démarrage ou CHECKPOINT. Ce fichier est au format texte non codé (plain text format).

SET WRITE_DELAY {TRUE | FALSE}

Le comportement de SET WRITE DELAY a changé avec l'introduction de la méthode sync() qui force le log à être complètement ré-écrit sur disque à intervalles donnés.

SET WRITE_DELAY {TRUE | FALSE} est interprété comme une synchronisation toutes les 60 secondes ou chaque seconde. SET WRITE_DELAY <n> ou n est un entier est interprété comme une synchronisation toutes les n secondes. La valeur par défaut actuelle est 60 secondes qui semble fournir le bon compromis. Dans des conditions de test intensives (INSERT/DELETE/UPDATE), l'impact sur les performances de SET WRITE_DELAY 1 est probablement d'environ 15% par rapport à celui de SET WRITE_DELAY 300.

La récupération d'un crash a été modifiée de sorte que toute ligne dans le fichier *.log incorrectement écrite (et qui donc provoque une erreur) termine le processus "refaire" (redo). Un message est envoyé à l'utilisateur au lieu de l'arrêt pur et simple de l'opération du moteur.

Accès NIO des fichiers *.data

New nio access layer for .data files speeds up most CACHED TABLE related operations very significantly. 90% speedups in TestCacheSize tests have been observed.


There must be enough available memory in the machine to allow a memory-mapped buffer for the entire *.data file. Beyond this size, the engine reverts to non-nio access.


----------------------------------------------------


BUILD


Reduction in JDK / JRE dependencies (see readmebuild.txt)


The supplied JAR is now compiled with JDK 1.4 and requires a JRE 1.4 or later to work. You can rebuild the JAR with JDK 1.3.x in order to use it with JRE 1.3 or earlier.


----------------------------------------------------


DOCUMENTATION


Documentation is now maintained mainly in XML format with HTML and PDF versions available.


----------------------------------------------------


UTILITIES


The SQL Tool is a powerful new utility in 1.7.2 and allows processing SQL commands via the shell or scripts.


The Transfer Tool utility saw a major upgrade just before the 1.7.2 release cycle. In this release some minor updates and bug fixes, together with significant speedup, have been intoduced.


The Database Manager has been enhanced slightly to include a command to save the result set in CSV format. The Swing version of Database Manager allows the user to sort the rows of the result set on any column.


The connection dialogue in the AWT version of Database Manager and Transfer Tool allows ds via the shell or scripts.


The Transfer Tool utility saw a major upgrade just before the 1.7.2 release cycle. In this release some minor updates and bug fixes, together with significant speedup, have been intoduced.


The Database Manager has been enhanced slightly to include a command to save the result set in CSV format. The Swing version of Database Manager allows the user to sort the rows of the result set on any column.


The connection dialogue in the AWT version of Database Manager and Transfer Tool allows saving and recalling connection URL's together with the user name and password.


----------------------------------------------------


END

Personal tools