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

From Apache OpenOffice Wiki
Jump to: navigation, search
m (Propriété de la connexion)
 
(10 intermediate revisions by the same user not shown)
Line 1: Line 1:
 +
<div style="float:left; background-color:lightyellow; border: 2px solid black; margin:0 1em 0 0.5em; padding:0 0.3em 0 0.3em; ">
 +
__TOC__
 +
</div>
 
= HSQLDB 1.7.2 Historique des changements =
 
= HSQLDB 1.7.2 Historique des changements =
 
(HSQLDB 1.7.2 CHANGE LOG)
 
(HSQLDB 1.7.2 CHANGE LOG)
Line 229: Line 232:
 
  <nowiki>jdbc:hsqldb:res:<path in jar></nowiki>
 
  <nowiki>jdbc:hsqldb:res:<path in jar></nowiki>
  
 +
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 ("'''/'''")
  
The URL type 'res' determines that the path that follows is a path into the JAR. The path must be all lowercase and begin with a forward 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.
  
The database can be readonly or files_readonly, depending on the value set in .properties file.
+
=== 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.
  
'OTHER' DATA TYPE
+
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 :
  
Change to handling of OTHER columns. It is no longer required that the classes for objects stored in OTHER columns to be available on the path of an HSQLDB engine running as a server. Classes must be available on the JDBC client's path.
+
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.
  
<nowiki>----------------------------------------------------</nowiki>
+
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
  
MULTIPLE IN-MEMORY AND SERVER DATABASES
+
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.
  
Support for multiple memory-only databases within the same JVM
+
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
  
Support for simultaneous multiple servers on different ports, multiple internal connections and multiple databases within the same JVM
+
'''Exemples:''' <tt>jdbc:hsqldb:mem:db1 jdbc:hsqldb:mem:maBase</tt>
  
 +
Le type de connexion, 'file:', peut être utilisé pour les connexions aux bases de données fichier. Exemple ci-dessous :
  
Each HSQLDB server or webserver can now serve up to 10 different databases.
+
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.
  
The server.properties and webserver.properties method for defining the databases has changed. The following properties should be used:
+
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é complètement révisées.
  
server.database.0 path_of_the_first_database
+
Entrez SELECT * FROM SYSTEM_TABLES pour voir la liste complète.
  
server.dbname.0 alias_for_the_first_database
+
=== 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.
  
Up to 10 databases can be defined but they must start from 0. The same applies to command line arguments for Server and WebServer.
+
=== 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.
  
The URL's for connecting to servers should have the alias of the database at the end. For example, to connect to the HSQL protocol server on the localhost use:
+
=== 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.
  
jdbc:hsqldb:hsql://localhost/alias_for_the_database
+
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.
  
where alias_for_the_database is the same string as defined in server.properties as server.dbname.n
+
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.
  
If not explicitly set, the default for server.dbname.0 is "" (empty string) so that old URL types continue to work.
+
<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.
  
Multiple memory-only database are supported by the use of:
+
=== Accès NIO des fichiers *.data ===
 +
Une nouvelle couche d'accès nio (NIO = Noeud d'Interconnexion des Opérateurs) pour les fichiers .data accélère la plupart des opérations relatives aux tables en cache très sensiblement. Observation de 90% d'accélération dans les tests de TestCacheSize.
  
 +
La machine doit avoir assez de mémoire disponible pour contenir un tampon de correspondance mémoire (memory-mapped buffer) pour le fichier .data en entier. Au delà de cette taille, le moteur retourne à un accès non-nio.
  
jdbc:hsqldb:mem:alias_for_the_first_database
+
=== Construction ===
 +
(BUILD)
  
jdbc:hsqldb:mem:alias_for_the_second_database
+
Réduction dans les dépendances JDK / JRE (voir readmebuild.txt)
  
 +
Le fichier JAR fournit est maintenant compilé avec JDK 1.4 et nécessite JRE 1.4 ou ultérieur pour pouvoir fonctionner. Vous pouvez reconstruire la JAR avec JDK 1.3.x de façon à pouvoir l'utiliser avec JRE 1.3 ou plus ancien.
  
Examples: jdbc:hsqldb:mem:db1 jdbc:hsqldb:mem:mydb
+
== Documentation ==
 +
La documentation est maintenant maintenue principalement au format XML, et des versions HTML et PDF sont disponibles.
  
 +
=== Utilitaires ===
 +
L'"outil SQL" est un nouvel utilitaire puissant dans la 1.7.2 et permet l'exécution de commandes SQL via le shell ou des scripts.
  
The connection type, 'file:', can be used for file database connections. Example below:
+
L'utilitaire "outil de transfert" a connu une mise à jour majeure juste avant la sortie de la 1.7.2. Dans cette version quelques mises à jours mineures et réparations de bogues ont été introduites, en même temps qu'une accélération significative.
  
 +
Le gestionnaire de base de données a été légèrement amélioré pour inclure une commande qui sauve le jeu de résultats au format CSV. La version Swing du gestionnaire de base de données permet à l'utilisateur de trier les lignes du jeu de résultats sur n'importe quelle colonne.
  
jdbc:hsqldb:file:mydb;ifexists=true
+
Le dialogue de connexion dans la version AWT (Voir la définition sur [http://jargonf.org/wiki/AWT Le Jargon Français]) du gestionnaire de base de données et de l'outil de transfert permet <font color="red"> '''le / la ds''' </font> via le shell ou les scripts. (The connection dialogue in the AWT version of Database Manager and Transfer Tool allows ds via the shell or scripts.)
  
 +
Le dialogue de connexion dans la version AWT du gestionnaire de base de données et de l'outil de transfert permet la sauvegarde et le rappel des URL's de connection avec le nom d'utilisateur et mot de passe.
  
The URL for connecting to a Servlet HTTP server must have a forward-slash at the end. Servlet serves only one database.
+
[[Category: FR/HSQLDB_Guide]]
 
+
 
+
jdbc:hsqldb:hsql://localhost:8080/servlet/HsqlServlet/
+
 
+
 
+
<nowiki>----------------------------------------------------</nowiki>
+
 
+
 
+
DATABASE METADATA
+
 
+
 
+
System table support and java.sql.DatabaseMetadate have been overhauled.
+
 
+
 
+
Use SELECT * FROM SYSTEM_TABLES to see the full list.
+
 
+
 
+
<nowiki>----------------------------------------------------</nowiki>
+
 
+
 
+
TEXT TABLES
+
 
+
 
+
Enhanced TEXT table handling and reporting of errors in CSV (source) files
+
 
+
 
+
TEXT TABLES encoding of the source file can now be specified. UTF-8 and other encodings can be used.
+
 
+
 
+
<nowiki>----------------------------------------------------</nowiki>
+
 
+
 
+
MEMORY USE AND OBJECT POOLING
+
 
+
 
+
An Object pool has been incorporated. This reduces memory usage to varying degrees depending on the contents of database tables and speeds up the database in most cases. Currently the size of the pool is hard-coded but it will be user adjustable in a future version.
+
 
+
 
+
<nowiki>----------------------------------------------------</nowiki>
+
 
+
 
+
PERSISTENCE
+
 
+
 
+
<nowiki>----------------</nowiki>
+
 
+
 
+
CHECKPOINT DEFRAG
+
 
+
 
+
Defragments the *.data file without shutting down the database
+
 
+
 
+
<nowiki>----------------</nowiki>
+
 
+
 
+
SET SCRIPTFORMAT {TEXT | BINARY | COMPRESSED }
+
 
+
 
+
Changes the format of the *.script file and performs a checkpoint.
+
 
+
 
+
Database script can be stored in binary or compressed binary formats, resulting in smaller size and faster loading.
+
 
+
 
+
<nowiki>----------------</nowiki>
+
 
+
 
+
The *.script file now contains only the DDL and data that is written at CHECKPOINT or SHUTDOWN. The COMPRESSED format has the side benefit of hiding the DDL and the admin password.
+
 
+
 
+
The *.log file now contains the statements executed since the last startup or CHECKPOINT. This file is in plain text format.
+
 
+
 
+
<nowiki>----------------</nowiki>
+
 
+
 
+
SET WRITE_DELAY {TRUE | FALSE}
+
 
+
 
+
<nowiki>SET WRITE_DELAY <n></nowiki>
+
 
+
 
+
The behaviour of SET WRITE_DELAY has changed with the introduction of the sync() method to force the log to be written out completely to disk at given intervals.
+
 
+
 
+
<nowiki>SET WRITE_DELAY {TRUE | FALSE} is interpreted as synch every 60 seconds or 1 second. SET WRITE_DELAY <n> where n is an integer is interpreted as synch every n seconds. The current default is 60 seconds which seems to provide the right balance. Under heavy INSERT/DELETE/UPDATE test conditions, the performance impact of SET WRITE_DELAY 1 is probably about 15% over that of SET WRITE_DELAY 300.</nowiki>
+
 
+
 
+
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.
+
 
+
 
+
<nowiki>----------------</nowiki>
+
 
+
 
+
NIO ACCESS FOR *.data FILES
+
 
+
 
+
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.
+
 
+
 
+
<nowiki>----------------------------------------------------</nowiki>
+
 
+
 
+
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.
+
 
+
 
+
<nowiki>----------------------------------------------------</nowiki>
+
 
+
 
+
DOCUMENTATION
+
 
+
 
+
Documentation is now maintained mainly in XML format with HTML and PDF versions available.
+
 
+
 
+
<nowiki>----------------------------------------------------</nowiki>
+
 
+
 
+
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.
+
 
+
 
+
<nowiki>----------------------------------------------------</nowiki>
+
 
+
 
+
END
+

Latest revision as of 18:47, 9 May 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é complètement révisées.

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

Une nouvelle couche d'accès nio (NIO = Noeud d'Interconnexion des Opérateurs) pour les fichiers .data accélère la plupart des opérations relatives aux tables en cache très sensiblement. Observation de 90% d'accélération dans les tests de TestCacheSize.

La machine doit avoir assez de mémoire disponible pour contenir un tampon de correspondance mémoire (memory-mapped buffer) pour le fichier .data en entier. Au delà de cette taille, le moteur retourne à un accès non-nio.

Construction

(BUILD)

Réduction dans les dépendances JDK / JRE (voir readmebuild.txt)

Le fichier JAR fournit est maintenant compilé avec JDK 1.4 et nécessite JRE 1.4 ou ultérieur pour pouvoir fonctionner. Vous pouvez reconstruire la JAR avec JDK 1.3.x de façon à pouvoir l'utiliser avec JRE 1.3 ou plus ancien.

Documentation

La documentation est maintenant maintenue principalement au format XML, et des versions HTML et PDF sont disponibles.

Utilitaires

L'"outil SQL" est un nouvel utilitaire puissant dans la 1.7.2 et permet l'exécution de commandes SQL via le shell ou des scripts.

L'utilitaire "outil de transfert" a connu une mise à jour majeure juste avant la sortie de la 1.7.2. Dans cette version quelques mises à jours mineures et réparations de bogues ont été introduites, en même temps qu'une accélération significative.

Le gestionnaire de base de données a été légèrement amélioré pour inclure une commande qui sauve le jeu de résultats au format CSV. La version Swing du gestionnaire de base de données permet à l'utilisateur de trier les lignes du jeu de résultats sur n'importe quelle colonne.

Le dialogue de connexion dans la version AWT (Voir la définition sur Le Jargon Français) du gestionnaire de base de données et de l'outil de transfert permet le / la ds via le shell ou les scripts. (The connection dialogue in the AWT version of Database Manager and Transfer Tool allows ds via the shell or scripts.)

Le dialogue de connexion dans la version AWT du gestionnaire de base de données et de l'outil de transfert permet la sauvegarde et le rappel des URL's de connection avec le nom d'utilisateur et mot de passe.

Personal tools