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

From Apache OpenOffice Wiki
Jump to: navigation, search
(New page: = HSQLDB 1.8.0 Historique des changements = Le développement de la version 1.8.0 a commencé vers le milieu 2004 avec pour but de sortir la nouvelle version en 2005. La fonctionnalité pr...)
 
 
(20 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.8.0 Historique des changements =
 
= HSQLDB 1.8.0 Historique des changements =
 
Le développement de la version 1.8.0 a commencé vers le milieu 2004 avec pour but de sortir la nouvelle version en 2005. La fonctionnalité principale prévue pour cette version était la capacité d'être utilisé par OpenOffice.org 2.0 comme moteur de base de données par défaut. Les versions candidates commencèrent à apparaitre en Janvier, jusqu'à la RC10 parue en Mai. Plusieurs commandes SQL, nouvelles ou améliorées, ont été introduites et de nouvelles capacités telles que la prise en charge de multiples objets de schéma dans chaque base de données, <font color="red"> '''database-wide collations'''</font> et les objets SQL ROLE ont été ajoutées. Des parties de <font color="red"> '''persistence engine'''</font> ont été ré-écrites pour une meilleure performance et des opérations de longue durée d'exécution en ligne.
 
Le développement de la version 1.8.0 a commencé vers le milieu 2004 avec pour but de sortir la nouvelle version en 2005. La fonctionnalité principale prévue pour cette version était la capacité d'être utilisé par OpenOffice.org 2.0 comme moteur de base de données par défaut. Les versions candidates commencèrent à apparaitre en Janvier, jusqu'à la RC10 parue en Mai. Plusieurs commandes SQL, nouvelles ou améliorées, ont été introduites et de nouvelles capacités telles que la prise en charge de multiples objets de schéma dans chaque base de données, <font color="red"> '''database-wide collations'''</font> et les objets SQL ROLE ont été ajoutées. Des parties de <font color="red"> '''persistence engine'''</font> ont été ré-écrites pour une meilleure performance et des opérations de longue durée d'exécution en ligne.
Line 12: Line 15:
  
 
== Améliorations SQL ==
 
== Améliorations SQL ==
 +
=== Schémas ===
 +
Prise en charge des schémas SQL. Chaque base de données peut contenir de multiples schémas. Les commandes suivantes ont été introduites :
  
−
SQL ENHANCEMENTS
+
CREATE SCHMEA <nom du schéma> AUTHORIZATION DBA
 +
DROP SCHEMA <nom du schéma> {CASCADE | RESTRICT}
 +
ALTER SCHEMA <nom du schéma> RENAME TO <new name>
 +
SET SCHEMA <nom du schéma>
  
−
----------------
+
Initialement, le schéma d'utilisateur par défaut est créé avec le nom PUBLIC. Ce schéma peut être renommé ou supprimé. Quand le dernier schéma d'utilisateur a été supprimé, un schéma vide par défaut doté du nom PUBLIC est recréé.
  
−
SCHEMAS
+
Les tables système appartiennent toutes à INFORMATION_SCHEMA. Pour accéder aux tables systèmes, soit SET SCHEMA ou INFORMATION_SCHEMA doivent être utilisés une fois ou il doit y être fait référence par des noms pleinement spécifiés, par exemple INFORMATION_SCHEMA.SYSTEM_TABLES.
  
−
Support for SQL schemas. Each database can contain multiple schemas. The following commands have been introduced:
+
D'une façon similaire tous les objets de la base de données indépendamment des colonnes peuvent être référencés par des noms de schéma explicites (pleinement qualifiés).
  
−
CREATE SCHMEA <schema name> AUTHORIZATION DBA
+
La commande CREATE SCHEMA peut être suivie d'autres commandes CREATE et GRANT sans insertion de point-virgule. Toutes ces commandes sont exécutées dans le contexte du schéma nouvellement créé. Un point-virgule termine une commande étendue CREATE SCHEMA.
−
DROP SCHEMA <schema name> {CASCADE | RESTRICT}
+
−
ALTER SCHEMA <schema name> RENAME TO <new name>
+
−
SET SCHEMA <schema name>
+
  
−
Initially, the default user schema will be created with the name PUBLIC. This schema can be renamed or dropped. When the last user schema has been dropped, an empty default schema with the name PUBLIC is created.
+
=== Rôles ===
 +
Prise en charge des roles du standard SQL.
  
−
System tables all belong to INFORMATION_SCHEMA. To access system tables, either SET SCHEMA INFORMATION_SCHEMA should be used once or they should be referred to by fully specified names, e.g. INFORMATION_SCHEMA.SYSTEM_TABLES
+
CREATE ROLE <role name>
 +
GRANT ... TO <role name>
 +
REVOKE ... FROM <role name>
 +
GRANT <role name> TO <user name>
 +
DROP ROLE <role name>
  
−
Similarly all database objects apart from columns can be referenced with fully qualified schema names.
+
Les commandes GRANT et REVOKE sont similaires à celles utilisées pour accorder des permissions de différents objets aux objets de l'utilisateur. Un role peut alors être accordé à ou retiré à différents utilisateurs, simplifiant ainsi la gestion des permissions.
  
−
The CREATE SCHEMA command can be followed by other CREATE and GRANT commands without an intervening semicolon. All such commands are executed in the context of the newly created schema. A semicolon terminates an extended CREATE SCHEMA command.
+
=== Tables temporaires globales ===
 +
L'implémentation de tables temporaires a changé pour se conformer aux standards SQL.
  
−
----------------
+
La définition d'une table GLOBAL TEMPORARY perdure avec la base de données. Quand une session (connexion JDBC) est démarrée, une instance vide de la table est créée. Une table temporaire peut être créée avec (valeur par défaut) ON COMMIT DELETE ROWS ou ON COMMIT PRESERVE ROWS ajouté à la définition de la table. Avec ON COMMIT PRESERVE ROWS, le contenu de la table n'est pas vidé quand la session est validée. Dans les deux cas, le contenu est nettoyé quand la session est fermée.
  
−
ROLES
+
=== Commandes de manipulation de schéma ===
 +
Plusieurs commandes de manipulation de schéma ont été améliorées.
  
−
Support for SQL standard roles.
+
Les tables, vues et séquences peuvent être supprimées avec l'option CASCADE. Cette option supprime directement (silently) toutes les tables et vues faisant référence à l'objet de base de données visé.
  
−
CREATE ROLE <role name>
+
DROP TABLE <table name> [IF EXISTS] [CASCADE];
−
GRANT ... TO <role name>
+
DROP VIEW <view name> [IF EXISTS] [CASCADE];
−
REVOKE ... FROM <role name>
+
DROP SEQUENCE <sequence name> [IF EXISTS] [CASCADE];
−
GRANT <role name> TO <user name>
+
−
DROP ROLE <role name>
+
  
−
The GRANT and REVOKE commands are similar to those used for granting permissions on different objects to USER objects. A role can then be granted to or revoked from different users, simplifying permission management.
+
ALTER TABLE <table name> DROP [COLUMN] supprime maintenant directement (silently) toute clé primaire ou contrainte unique déclarée sur la colonne (à l'exclusion des contraintes multi-colonnes).
  
−
----------------
+
ALTER TABLE <table name> ADD [COLUMN] accepte maintenant la clé primaire et les attributs identity.
  
−
GLOBAL TEMPORARY TABLES
+
=== Manipulation de colonne ===
 +
Support pour les conversions de types, <font color="red">'''nullability and identity attributes of a column'''</font>
  
−
The implementation of temporary tables has changed to conform to SQL standards.
+
ALTER TABLE <NomDeTable> ALTER [COLUMN] <NomDeColonne> <DefinitionDeColonne>
  
−
The definition of a GLOBAL TEMPORARY table persists with the database. When a session (JDBC Connection) is started, an empty instance of the table is created. Temporary tables can be created with (the default) ON COMMIT DELETE ROWS or ON COMMIT PRESERVE ROWS added to table definition. With ON COMMIT PRESERVE ROWS, the table contents are not cleared when the session commits. In both cases, the contents are cleared when the session is closed.
+
<DefinitionDeColonne> a la même syntaxe que la définition de colonne normale. La nouvelle définition de colonne remplace l'ancienne, il est donc possible d'ajouter/supprimer une expression DEFAULT, une contrainte NOT NULL, ou une définition IDENTITY. Il n'est pas possible de changer la clé primaire avec cette commande.
  
−
----------------
+
* La colonne doit déjà être une colonne PK (PK = Primary Key = Clé Primaire) pour accepter une définition IDENTITY.
 +
* Si la colonne est déjà une colonne IDENTITY et qu'il n'y a pas de définition IDENTITY, l'attribut IDENTITY existant est supprimé.
 +
* L'expression par défaut sera celui de la nouvelle définition, ce qui signifie qu'une valeur par défaut existante peut être supprimée par omission, ou qu'une nouvelle valeur par défaut peut être ajoutée.
 +
* L'attribut NOT NULL sera celui de la nouvelle définition, comme ci-dessus.
 +
* Selon le type de conversion, la table doit être vide pour que la commande fonctionne. Elle fonctionne en général toujours quand la conversion est possible et les valeurs individuelles existantes peuvent toutes être converties.
  
−
SCHEMA MANIPULATION COMMANDS
+
On utilise une syntaxe différente pour changer la prochaine valeur d'une colonne IDENTITY :
  
−
Several schema manipulation commands have been enhanced.
+
ALTER TABLE <table name> ALTER [COLUMN] <column name> RESTART WITH <n>
  
−
Tables, views and sequences can be dropped with the CASCADE option. This silently drops all tables and views that reference the given database object.
+
=== Ajouter ou supprimer des clés primaires ===
  
−
DROP TABLE <table name> [IF EXISTS] [CASCADE];
+
Il est maintenant possible d'ajouter ou de supprimer une clé primaire.
−
DROP VIEW <view name> [IF EXISTS] [CASCADE];
+
−
DROP SEQUENCE <sequence name> [IF EXISTS] [CASCADE];
+
  
−
ALTER TABLE <table name> DROP [COLUMN] now silently drops any primary key or unique constraint declared on the column (excluding multi-column constraints).
+
Une clé primaire existante à supprimer ne doit pas être référencée dans une contrainte de clé externe (c.a.d. pas de liaisons avec une autre table). Si une table a une colonne IDENTITY, supprimer une clé primaire supprimera les attributs d'identité de la colonne mais préservera les données.
  
−
ALTER TABLE <table name> ADD [COLUMN] now accepts primary key and identity attributes.
+
Lors de l'ajout d'une clé primaire, une contrainte NOT NULL est automatiquement ajoutée aux définitions de colonne. Les données de la table pour les colonnes d'une clé primaire nouvellement déclarée ne doivent pas contenir de valeurs nulles.
  
−
----------------
+
ALTER TABLE <name> ADD CONSTRAINT <cname> PRIMARY KEY(collist);
 +
ALTER TABLE <name> DROP CONSTRAINT <cname>;
 +
ALTER TABLE <name> DROP PRIMARY KEY; // alternative syntax
  
−
COLUMN MANIPULATION
+
=== SIZE ENFORCEMENT ===
 +
La propriété de base de données <tt>sql.enforce_strict_size=true</tt> a maintenant une plus grande portée (un effet plus large).
  
−
Support for converting type, nullability and identity attributes of a column
+
Les longueurs précédentes pour les types CHAR / VARCHAR pouvaient être vérifiées et le remplissage exécuté seulement lors de l'insertion / mise à jour de lignes. <font color="red">(Previously CHAR /VARCHAR lengths could be checked and padding performed only when inserting / updating rows.)</font> Prise en charge supplémentaire de CHAR(n), VARCHAR(n), NUMERIC(p,s) et DECIMAL(p,s) incluant la sémantique des fonctions standards SQL cast et convert. Les déclarations CHAR et VARCHAR requièrent maintenant un paramètre Taille (size). Une déclaration CHAR sans paramètre size est interprété comme CHAR(1). TIMESTAMP(0) et TIMESTAMP(6) sont aussi supportés, avec une précision représentant une résolution en fraction de seconde (sub-second).
  
−
ALTER TABLE <table name> ALTER [COLUMN] <column name> <column definition>
+
Une fonction CAST(c AS VARCHAR(2)) explicite tronquera toujours la chaîne de caractères. Une fonction CAST(n AS NUMERIC(p)) explicite exécutera toujours la conversion ou éliminera le superflu si n est en dehors des limites. <font color="red">(Explicit CAST(n AS NUMERIC(p)) will always perform the conversion or throw if n is out of bounds.)</font> Toutes les autres conversions implicites et explicites de CHAR(n) et VARCHAR(n) sont assujetties aux règles du standard SQL.
  
−
<column definition> has the same syntax as normal column definition. The new column definition replaces the old one, so it is possible to add/remove a DEFAULT expression, a NOT NULL constraint, or an IDENTITY definition. No change to the primary key is allowed with this command.
+
=== Les expressions ALL et ANY ===
 +
Pleine prise en charge de ALL(SELECT ....) et ANY(SELECT ....) avec les opérateurs de comparaison suivants : =, >, <, <>, >=, <=
  
−
- The column must already be a PK column to accept an IDENTITY definition.
+
'''Exemple:'''
−
- If the column is already an IDENTITY column and there is no IDENTITY definition, the existing IDENTITY attribute is removed.
+
−
- The default expression will be that of the new definition, meaning an existing default can be dropped by omission, or a new default added.
+
−
- The NOT NULL attribute will be that of the new definition, similar to above.
+
−
- Depending on the conversion type, the table may have to be empty for the command to work. It always works when the conversion is possible in general and the individual existing values can all be converted.
+
  
−
A different syntax can be used to change the next value from an IDENTITY column:
+
SELECT ... WHERE <value expression> >= ALL(SELECT ...)
  
−
ALTER TABLE <table name> ALTER [COLUMN] <column name> RESTART WITH <n>
+
=== LIMIT et OFFSET ===
 +
Nouvelle syntaxe alternative pour LIMIT à la fin d'une requête :
  
−
----------------
+
LIMIT L [OFFSET O]
  
−
ADDING AND DROPPING PRIMARY KEYS
+
L'utilisation de LIMIT en combinaison avec la clause ORDER BY est maintenant possible dans les sous-requêtes et déclarations SELECT entre parenthèses (brackets) faisant parties de l'UNION ou autres opérations.
  
−
It is now possible to add or drop a primary key.
+
Une clause ORDER BY ou LIMIT s'applique au résultat complet de l'UNION et autres opérations ou alternativement
 +
ou alternativement à l'une de ses composantes dépendant du nombre se parenthèses utilisées. Dans le premier exemple le focus (scope) est sur le second SELECT, alors que dans la seconde requête, la portée (scope) est le résultat de l'UNION.
  
−
An existing primary key that is to be removed should not be referenced in a FOREIGN KEY constraint. If a table has an IDENTITY column, removing a primary key will remove the identity attribute of the column but leave the actual data.
+
SELECT ... FROM ... UNION
 +
(SELECT ... FROM ... ORDER BY .. LIMIT)
  
−
When adding a primary key, a NOT NULL constraint is automatically added to the column definitions. The table data for the columns of a newly declared primary key should not contain null values.  
+
SELECT ... FROM ... UNION
 +
SELECT ... FROM ... ORDER BY .. LIMIT
  
−
ALTER TABLE <name> ADD CONSTRAINT <cname> PRIMARY KEY(collist);
+
Prise en charge de ORDER BY, LIMIT et OFFSET dans les déclarations CREATE VIEW.
−
ALTER TABLE <name> DROP CONSTRAINT <cname>;
+
−
ALTER TABLE <name> DROP PRIMARY KEY; // alternative syntax
+
  
−
----------------
 
  
−
SIZE ENFORCEMENT
+
=== Indexations (COLLATIONS) ===
 +
http://en.wikipedia.org/wiki/Collation
  
 +
Chaque base de données peut avoir sa propre collation. La commande SQL ci-dessous définit la collation parmi le jeu de collations à la source de org.hsqldb.Collation :
 +
 +
SET DATABASE COLLATION <Nom de collation entre guillemets>
  
−
The database property sql.enforce_strict_size=true has now a wider effect.
+
Cette commande n'a d'effet que sur une base de données vide. <font color="red">'''Once it has been issued, the database can be opened in any JVM locale and will retain its collation.'''</font>
  
−
Previously CHAR /VARCHAR lengths could be checked and padding performed only when inserting / updating rows. Added support for CHAR(n), VARCHAR(n), NUMERIC(p,s) and DECIMAL(p,s) including SQL standard cast and convert semantics. CHAR and VARCHAR declarations now require a size parameter. A CHAR declaration without a size parameter is interpreted as CHAR(1). TIMESTAMP(0) and TIMESTAMP(6) are also supported, with the precision representing the sub-second resolution.
+
La propriété <tt>sql.compare_in_locale=true</tt> n'est plus supportée. Si cette ligne existe dans un fichier .properties, elle basculera la base de données vers la collation pour l'option par défaut courante.
  
−
Explicit CAST(c AS VARCHAR(2)) will always truncate the string. Explicit CAST(n AS NUMERIC(p)) will always perform the conversion or throw if n is out of bounds. All other implicit and explicit conversions to CHAR(n) and VARCHAR(n) are subject to SQL standard rules.
 
  
−
----------------
+
=== Résolution de nom dans les requêtes ===
 +
(See [http://en.wikipedia.org/wiki/Parsing#Parser Parsing] in Wikipedia.)
  
−
ALL and ANY expressions
+
Des améliorations de <font color="red">'''Parsing'''</font> permettent que des mots réservés SQL puissent être utilisés comme identifiants quand ils sont entre guillemets, et donc servir dans des requêtes. Par exemple :
 +
CREATE TABLE "TABLE" ("INTEGER" INTEGER)
  
−
Full support for ALL(SELECT ....) and ANY(SELECT ....) with comparison operators: =, >, <, <>, >=, <=
+
Améliorations du traitement des alias de colonnes et de tables dans les conditions des requêtes.
−
Example:
+
  
−
SELECT ... WHERE <value expression> >= ALL(SELECT ...)
+
=== Améliorations ===
 +
Depuis la version 1.7.3, l'évaluation des expressions booléennes a changé pour se conformer aux standards SQL. Toute expression BOOLEAN peut être TRUE, FALSE, ou UNDEFINED. Le résultat indéfini est l'équivalent de NULL.
  
−
LIMIT and OFFSET
+
Changement optionnel du comportement des transactions dans le mode par défaut READ UNCOMMITTED. Quand la propriété de la base de données <tt>sql.tx_no_multi_write=true</tt> a été définie, une transaction ne peut plus supprimer ou mettre à jour une ligne qui a déjà été mise à jour ou ajoutée par une autre transaction non validée (uncommitted).
  
−
New alternative syntax for LIMIT at the end of the query:
+
Support d'un forçage de type ([http://jargonf.org/wiki/cast casting]) de TIME en TIMESTAMP, par l'utilisation de CURRENT_DATE
−
 
+
−
LIMIT L [OFFSET O]
+
−
 
+
−
It is now possible to use LIMIT combined with ORDER BY in subqueries and SELECT statements in brackets that are terms of UNION or other set operations.
+
−
 
+
−
An ORDER BY or LIMIT clause applies to the complete result of the UNION and other set operations or alternatively to one of its components depending on how parentheses are used. In the first example the scope is the second SELECT, while in the second query, the scope is the result of the UNION.
+
−
 
+
−
SELECT ... FROM ... UNION
+
−
(SELECT ... FROM ... ORDER BY .. LIMIT)
+
−
 
+
−
SELECT ... FROM ... UNION
+
−
SELECT ... FROM ... ORDER BY .. LIMIT
+
−
 
+
−
 
+
−
Support for ORDER BY, LIMIT and OFFSET in CREATE VIEW statements
+
−
 
+
−
----------------
+
−
 
+
−
COLLATIONS
+
−
 
+
−
Each database can have its own collation. The SQL command below sets the collation from the set of collations in the source for org.hsqldb.Collation:
+
−
 
+
−
SET DATABASE COLLATION <double quoted collation name>
+
−
 
+
−
The command has an effect only on an empty database. Once it has been issued, the database can be opened in any JVM locale and will retain its collation.
+
−
 
+
−
The property sql.compare_in_locale=true is no longer supported. If the line exists in a .properties file, it will switch the database to the collation for the current default. 
+
−
 
+
−
----------------
+
−
 
+
−
NAME RESOLUTION IN QUERIES
+
−
 
+
−
Parsing enhancements allow all reserved SQL words to be used as identifiers when double-quoted and then used in queries. E.g. CREATE TABLE "TABLE" ("INTEGER" INTEGER)
+
−
 
+
−
Enhancements to resolve column and table aliases used in query conditions.
+
−
 
+
−
----------------
+
−
 
+
−
ENHANCEMENTS
+
−
 
+
−
Since 1.7.3, the evaluation of BOOLEAN expressions has changed to conform to SQL standards. Any such expression can be TRUE, FALSE, or UNDEFINED. The UNDEFINED result is equivalent to NULL.
+
−
 
+
−
Optional changed behaviour of transactions in the default READ UNCOMMITTED mode. When a database property, sql.tx_no_multi_write=true has been set, a transaction is no longer allowed to delete or update a row that has already been updated or added by another uncommitted transaction.
+
−
 
+
−
Support for correct casting of TIME into TIMESTAMP, using CURRENT_DATE  
+
−
 
+
−
 
+
−
----------------
+
−
 
+
−
BUG FIXES
+
−
 
+
−
Fixed reported bug with NOT LIKE and null values
+
−
 
+
−
Fixed bug with OR conditions in OUTER JOIN
+
−
 
+
−
Fixed bug with duplicated closing of prepared statements
+
−
 
+
−
Fixed various parsing anomalies where SQL commands were accepted when quoted, double-quoted or prefixed with an identifier, or identifiers were accepted in single quotes. Example of a command that is no-longer tolerated:
+
−
 
+
−
Malformed query: MY. "SELECT" ID FROM 'CUSTOMER' IF.WHERE ID=0; 
+
−
Actual query: SELECT ID FROM CUSTOMER WHERE ID=0;
+
−
 
+
−
Fixed issue with illegal user names
+
−
 
+
−
Fixed TEXT table implementation to maintain the commit status of rows during recovery from an abrupt shutdown. Uncommitted changes will not appear in TEXT tables.
+
−
 
+
−
----------------
+
−
 
+
−
STORAGE AND PERSISTENCE IMPROVEMENTS
+
−
 
+
−
New connection property for setting the default table type when CREATE TABLE is used. The connection property, hsqldb.default_table_type=cached will set the default to CACHED tables, or the SET PROPERTY command can be used. Values, "cached" and "memory" are allowed.
+
−
+
  
−
Improved support for text tables. Newline support in quoted fields is now complete. It is now possible to save and restore the first line header of a CSV file when ignore_first=true is specified. When a text table is created with a new source (CSV) file, and ignore_first=true has been specified the following command can be used to set a user defined string as the first line:
+
== Réparations de bogues ==
−
SET TABLE <table name> SOURCE HEADER <double quoted string>.
+
* Avec NOT LIKE et les valeurs nulles.
 +
* Avec les conditions OR dans les jointures externes. (OUTER JOIN)
 +
* Avec la fermeture dupliquée des déclarations préparées. (prepared statements)
  
−
A new application log has been introduced as an optional feature. The property/value pair "hsqldb.applog=1" can be used in the first connection string to log some important messages. The default is "hsqldb.applog=0", meaning no logging. A file with the ending ".app.log" is generated alongside the rest of the database files for this purpose.  
+
Réparation de diverses anomalies de <font color="red">'''parsing'''</font> où les commandes SQL étaient acceptées entre apostrophes, entre guillemets ou préfixées par un identificateur, ou les identificateurs étaient acceptés entre apostrophes. Exemple d'une commande qui n'est plus maintenant tolérée :
  
−
In the current version, only the classes used for file persistence, plus any error encountered while processing the .log file after an abnormal end, are logged.
+
;<tt>Requête malformée</tt>:MY. "SELECT" ID FROM 'CUSTOMER' IF.WHERE ID=0;
 +
;<tt>Requête actuelle</tt>:SELECT ID FROM CUSTOMER WHERE ID=0;
  
−
Note that the JDBC driver and the engine for 1.8.0 cannot be mixed with those of earlier versions in client/server setup. Check your classpaths and use the same version of the engine for both client and server.
+
* Problème réglé avec les noms d'utilisateur illégaux.
 +
* Réparation dans l'implémentation de la table TEXT pour maintenir le statut validé des lignes durant le processus de récupération suivant un arrêt impromptu. Les changements non validés n'apparaîtront pas dans les tables TEXT.
  
−
New property for larger data file limits is introduced. Once set, the limit will go up to 8GB. The property can be set with the following SQL command only when the database has no tables (new database).
+
=== Amélioration du stockage et de la persistance ===
 +
Nouvelle propriété de connexion pour le réglage de type de table par défaut lors de l'utilisation de CREATE TABLE. La propriété de connexion <tt>hsqldb.default_table_type=cached</tt> assignera la valeur par défaut à CACHED. La commande SET PROPERTY peut également être utilisée. Les valeurs permises sont "cached" et "memory".
  
−
SET PROPERTY "hsqldb.cache_file_scale" 8
+
Support amélioré des tables texte. Le support dans la nouvelle ligne de champs entre apostrophes est maintenant terminé. <font color="red">(Newline support in quoted fields is now complete.)</font> Il est maintenant possible de sauver et recharger la première ligne de titre d'un fichier CSV avec <tt>ignore_first=true</tt>. Lors de la création d'une table texte avec un nouveau fichier source (CSV) et si <tt>ignore_first=true</tt> a été spécifié alors la commande suivante peut permettre d'établir une chaîne de caractères définie par l'utilisateur comme première ligne :
  
−
To apply the change to an existing database, SHUTDOWN SCRIPT should be performed first, then the property=value line below should be added to the .properties file before reopening the database:
+
SET TABLE <NomDeTable> SOURCE HEADER <Chaîne entre guillemets>.
  
−
hsqldb.cache_file_scale=8
+
Une nouvelle application journal (application log) a vu le jour en tant qu'option. Utilisez la paire propriété/valeur "<tt>hsqldb.applog=1</tt>" dans la première chaîne de connexion pour journaliser des messages importants. La valeur par défaut est "<tt>hsqldb.applog=0</tt>", qui signifie "pas d'historique". Un nouveau fichier terminant par ".app.log" est généré à coté des autres fichiers de la base de données pour cette option.
  
 +
Dans la version en cours, seulement les classes utilisées pour la persistance du fichier, plus chaque erreur rencontrée lors du traitement du fichier .log suite à un arrêt anormal sont journalisées.
  
−
New property allows a CHECKPOINT DEFRAG to be performed automatically whenever CHECKPOINT is performed internally or via a user command.
+
Veuillez noter que le pilote JDBC et le moteur de la 1.8.0 ne peuvent être mélangés avec ceux des versions précédentes dans le paramétrage client/serveur. Vérifiez les chemins de vos classes et utilisez la même version du moteur pour le client et le serveur.
  
−
SET CHECKPOINT DEFRAG n
+
Introduction d'une nouvelle propriété pour repousser les limites des plus grands fichiers de données. Une fois paramétrée, la limite maximum est maintenant de 8 Go. Cette propriété se paramètre par la commande SQL suivante seulement quand la base de données ne possède aucune table (nouvelle base de données) :
  
−
The parameter n is the megabytes of abandoned space in the .data file. When a CHECKPOINT is performed either as a result of the .log file reaching the limit set by "SET LOGSIZE m", or by the user issuing a CHECKPOINT command, the amount of space abandoned during the session is checked and if it is larger than n, a CHECKPOINT DEFRAG is performed instead of a checkpoint.
+
SET PROPERTY "hsqldb.cache_file_scale" 8
  
−
Rewrite of log and cache handling classes, including:
+
Pour appliquer le changement à une base de données existante, il faut appliquer d'abord SHUTDOWN SCRIPT, et la ligne propriété=valeur ci dessous doit être ajoutée au fichier .properties avant réouverture de la base de données :
−
New deleted block manager with more efficient deleted block reuse.
+
−
Faster log processing after an abnormal termination.
+
−
Better checks when maximum data file size is reached.
+
−
Better recovery when maximum data file size is reached.
+
  
−
Support for the res: connection protocol (database files in a jar) has been
+
hsqldb.cache_file_scale=8
−
extended to allow CACHED tables.
+
  
−
----------------
+
Une nouvelle propriété permet à CHECKPOINT DEFRAG d'être exécuté automatiquement soit si le moteur (en interne) effectue un CHECKPOINT ou via une commande utilisateur :
  
−
JDBC AND OTHER ENHANCEMENTS
+
SET CHECKPOINT DEFRAG n
  
−
ResultSetMetaData reports identical precision/scale in embedded and client/server modes
+
Le paramètre n est le nombre de mégaoctets d'espace inutilisé (abandonné) dans le fichier .data. Lors de l'exécution d'un CHECKPOINT, (soit parce que le fichier .log atteint la limite définie par "SET LOGSIZE m", ou parce que l'utilisateur envoie une commande CHECKPOINT) la taille de l'espace abandonné durant la session est vérifiée et si elle est plus grande que n, un CHECKPOINT DEFRAG est exécuté au lieu du simple CHECKPOINT.
  
−
When PreparedStatement.setTimestamp() and ResultSet.getTimestamp() are used with a Calendar parameter, the result is symmetrical if the time zones are equal.
+
Réécriture du log et du cache de manipulation des classes, dont :
  
−
Added public shutdown() method to Server.
+
* Nouveau gestionnaire de délétion des blocs doté d'une réutilisation des blocs supprimés plus efficiente.
 +
* Processus de journalisation (log) plus rapide suite à un arrêt anormal.
 +
* Meilleures vérifications quand la taille maximum d'un fichier de données est atteinte.
 +
* Meilleure récupération quand la taille maximum d'un fichier de données est atteinte.
  
−
Enhancements to DatabaseManagerSwing and SqlTool
+
La prise en charge du protocole de connexion res: (fichiers de base de données dans une jar) a été étendue pour permettre les tables CACHED.
  
−
----------------
+
=== JDBC et autres améliorations ===
 +
<tt>ResultSetMetaData</tt> délivre une précision/échelle identique dans les deux modes intégré et client/serveur.
  
−
BUG FIX
+
Quand on utilise <tt>PreparedStatement.setTimestamp()</tt> et <tt>ResultSet.getTimestamp()</tt> avec un paramètre de calendrier, le résultat est identique <font color="red">(symmetrical)</font> si les zones de temps sont les mêmes.
  
−
Fixed bug where two indexes where switched, causing wrong results in some queries in the following circumstances:
+
Ajout d'une méthode publique <tt>shutdown()</tt> au serveur.
  
−
CREATE TABLE is executed.
+
Améliorations dans DatabaseManagerSwing et SqlTool.
−
ALTER TABLE ADD FORIEGN KEY is used to create an FK on a different table that was already present when the first command was issued.
+
−
CREATE INDEX is used to add an index.
+
−
Data is added to the table.
+
−
Database is shutdown.
+
−
Database is restarted.
+
−
At this point the indexes are switched and queries that use either of the indexes will not return the correct set of rows. Ifst command was issued.
+
−
CREATE INDEX is used to add an index.
+
−
Data is added to the table.
+
−
Database is shutdown.
+
−
Database is restarted.
+
−
At this point the indexes are switched and queries that use either of the indexes will not return the correct set of rows. If data is not added prior to the first shutdown, the database will works as normal.
+
  
−
----------------
+
=== Réparation de bogue ===
 +
Lors d'un passage entre deux index, causant des résultats faux dans certaines requêtes et dans les circonstances suivantes :
  
−
UPGRADING DATABASES
+
* CREATE TABLE est exécuté.
 +
* Utilisation de ALTER TABLE ADD FOREIGN KEY pour créer une clé externe sur une table différente de celle déjà présente quand la première commande a été initiée. <font color="red">(is used to create an FK on a different table that was already present when the first command was issued.)</font>
 +
* Utilisation de CREATE INDEX pour ajouter un index.
 +
* Les données sont ajoutées à la table.
 +
* Fermeture de la base de données.
 +
* Redémarrage de la base de données.<br/>
 +
A ce moment les index sont inactifs (switched) et les requêtes utilisant l'un ou l'autre de ces index ne retourneront pas le bon jeu de lignes. <font color="red">'''Ifst command was issued.'''</font>
  
−
Databases that do not contain CACHED tables can be opened with the new version. For databases with CACHED tables, if they are created with versions 1.7.2 or 1.7.3, the SHUTDOWN SCRIPT command should be run once on the database prior to opening with the new version. For databases created with earlier versions, the instructions in the Advanced Topics section of The Guide should be followed.
+
* Utilisation de CREATE INDEX pour ajouter un index.
 +
* Les données sont ajoutées à la table.
 +
* Fermeture de la base de données.
 +
* Redémarrage de la base de données.<br/>
 +
A ce moment les index sont inactifs (switched) et les requêtes utilisant l'un ou l'autre de ces index ne retourneront pas le bon jeu de lignes. Si aucune donnée n'a été ajoutée avant la première fermeture, la base de données fonctionnera normalement.
  
−
----------------
+
=== Mettre à jour les bases de données ===
 +
Les base de données qui ne contiennent pas de tables CACHED peuvent être ouvertes avec la nouvelle version. Pour les bases de données munies de tables CACHED qui ont été créées avec les versions 1.7.2 ou 1.7.3, la commande SHUTDOWN SCRIPT doit être exécutée une fois sur la base de données avant de l'ouvrir avec la nouvelle version. Si les bases de données ont été créées avec des versions antérieures, vous devez suivre les instructions dans la section "[[Fr.openoffice.org/FAQ/Base/Guide_HSQLDB/TDM#Chapitre_4._Consid.C3.A9rations_avanc.C3.A9es|Considérations avancées]]" de ce guide.
  
−
OPEN OFFICE INTEGRATION
+
=== Intégration dans {{OOo}} ===
 +
Lors de l'utilisation de {{OOo}} comme base de données par défaut, plusieurs valeurs par défaut et propriétés sont automatiquement définies :
  
−
When used in OpenOffice.org as the default database, several defaults and properties are set automatically:
+
* CREATE TABLE ... La valeur par défaut est CREATE CACHED TABLE ...
 +
* hsqldb.cache_scale=13
 +
* hsqldb.cache_size_scale=8
 +
* hsqldb.log_size=10
 +
* SET WRITE DELAY 2
 +
* sql.enforce_strict_size=true
  
−
CREATE TABLE ... defaults to CREATE CACHED TABLE ...
+
[[Category: FR/HSQLDB_Guide]]
−
hsqldb.cache_scale=13
+
−
hsqldb.cache_size_scale=8
+
−
hsqldb.log_size=10
+
−
SET WRITE DELAY 2
+
−
sql.enforce_strict_size=true
+

Latest revision as of 18:47, 9 May 2009

HSQLDB 1.8.0 Historique des changements

Le développement de la version 1.8.0 a commencé vers le milieu 2004 avec pour but de sortir la nouvelle version en 2005. La fonctionnalité principale prévue pour cette version était la capacité d'être utilisé par OpenOffice.org 2.0 comme moteur de base de données par défaut. Les versions candidates commencèrent à apparaitre en Janvier, jusqu'à la RC10 parue en Mai. Plusieurs commandes SQL, nouvelles ou améliorées, ont été introduites et de nouvelles capacités telles que la prise en charge de multiples objets de schéma dans chaque base de données, database-wide collations et les objets SQL ROLE ont été ajoutées. Des parties de persistence engine ont été ré-écrites pour une meilleure performance et des opérations de longue durée d'exécution en ligne.

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

June 2005

Fred Toussi

Maintainer, HSQLDB Project http://hsqldb.sourceforge.net

Améliorations SQL

Schémas

Prise en charge des schémas SQL. Chaque base de données peut contenir de multiples schémas. Les commandes suivantes ont été introduites : 

CREATE SCHMEA <nom du schéma> AUTHORIZATION DBA
DROP SCHEMA <nom du schéma> {CASCADE | RESTRICT}
ALTER SCHEMA <nom du schéma> RENAME TO <new name>
SET SCHEMA <nom du schéma>

Initialement, le schéma d'utilisateur par défaut est créé avec le nom PUBLIC. Ce schéma peut être renommé ou supprimé. Quand le dernier schéma d'utilisateur a été supprimé, un schéma vide par défaut doté du nom PUBLIC est recréé.

Les tables système appartiennent toutes à INFORMATION_SCHEMA. Pour accéder aux tables systèmes, soit SET SCHEMA ou INFORMATION_SCHEMA doivent être utilisés une fois ou il doit y être fait référence par des noms pleinement spécifiés, par exemple INFORMATION_SCHEMA.SYSTEM_TABLES.

D'une façon similaire tous les objets de la base de données indépendamment des colonnes peuvent être référencés par des noms de schéma explicites (pleinement qualifiés).

La commande CREATE SCHEMA peut être suivie d'autres commandes CREATE et GRANT sans insertion de point-virgule. Toutes ces commandes sont exécutées dans le contexte du schéma nouvellement créé. Un point-virgule termine une commande étendue CREATE SCHEMA.

Rôles

Prise en charge des roles du standard SQL. 

CREATE ROLE <role name>
GRANT ... TO <role name>
REVOKE ... FROM <role name>
GRANT <role name> TO <user name>
DROP ROLE <role name>

Les commandes GRANT et REVOKE sont similaires à celles utilisées pour accorder des permissions de différents objets aux objets de l'utilisateur. Un role peut alors être accordé à ou retiré à différents utilisateurs, simplifiant ainsi la gestion des permissions.

Tables temporaires globales

L'implémentation de tables temporaires a changé pour se conformer aux standards SQL.

La définition d'une table GLOBAL TEMPORARY perdure avec la base de données. Quand une session (connexion JDBC) est démarrée, une instance vide de la table est créée. Une table temporaire peut être créée avec (valeur par défaut) ON COMMIT DELETE ROWS ou ON COMMIT PRESERVE ROWS ajouté à la définition de la table. Avec ON COMMIT PRESERVE ROWS, le contenu de la table n'est pas vidé quand la session est validée. Dans les deux cas, le contenu est nettoyé quand la session est fermée.

Commandes de manipulation de schéma

Plusieurs commandes de manipulation de schéma ont été améliorées.

Les tables, vues et séquences peuvent être supprimées avec l'option CASCADE. Cette option supprime directement (silently) toutes les tables et vues faisant référence à l'objet de base de données visé.

DROP TABLE [IF EXISTS] [CASCADE]; DROP VIEW <view name> [IF EXISTS] [CASCADE]; DROP SEQUENCE <sequence name> [IF EXISTS] [CASCADE]; ALTER TABLE
DROP [COLUMN] supprime maintenant directement (silently) toute clé primaire ou contrainte unique déclarée sur la colonne (à l'exclusion des contraintes multi-colonnes). ALTER TABLE
ADD [COLUMN] accepte maintenant la clé primaire et les attributs identity.

Manipulation de colonne

Support pour les conversions de types, nullability and identity attributes of a column 

ALTER TABLE <NomDeTable> ALTER [COLUMN] <NomDeColonne> <DefinitionDeColonne>

<DefinitionDeColonne> a la même syntaxe que la définition de colonne normale. La nouvelle définition de colonne remplace l'ancienne, il est donc possible d'ajouter/supprimer une expression DEFAULT, une contrainte NOT NULL, ou une définition IDENTITY. Il n'est pas possible de changer la clé primaire avec cette commande.

  • La colonne doit déjà être une colonne PK (PK = Primary Key = Clé Primaire) pour accepter une définition IDENTITY.
  • Si la colonne est déjà une colonne IDENTITY et qu'il n'y a pas de définition IDENTITY, l'attribut IDENTITY existant est supprimé.
  • L'expression par défaut sera celui de la nouvelle définition, ce qui signifie qu'une valeur par défaut existante peut être supprimée par omission, ou qu'une nouvelle valeur par défaut peut être ajoutée.
  • L'attribut NOT NULL sera celui de la nouvelle définition, comme ci-dessus.
  • Selon le type de conversion, la table doit être vide pour que la commande fonctionne. Elle fonctionne en général toujours quand la conversion est possible et les valeurs individuelles existantes peuvent toutes être converties.

On utilise une syntaxe différente pour changer la prochaine valeur d'une colonne IDENTITY :

ALTER TABLE
ALTER [COLUMN] <column name> RESTART WITH <n>

Ajouter ou supprimer des clés primaires

Il est maintenant possible d'ajouter ou de supprimer une clé primaire.

Une clé primaire existante à supprimer ne doit pas être référencée dans une contrainte de clé externe (c.a.d. pas de liaisons avec une autre table). Si une table a une colonne IDENTITY, supprimer une clé primaire supprimera les attributs d'identité de la colonne mais préservera les données.

Lors de l'ajout d'une clé primaire, une contrainte NOT NULL est automatiquement ajoutée aux définitions de colonne. Les données de la table pour les colonnes d'une clé primaire nouvellement déclarée ne doivent pas contenir de valeurs nulles. 

ALTER TABLE <name> ADD CONSTRAINT <cname> PRIMARY KEY(collist);
ALTER TABLE <name> DROP CONSTRAINT <cname>;
ALTER TABLE <name> DROP PRIMARY KEY; // alternative syntax

SIZE ENFORCEMENT

La propriété de base de données sql.enforce_strict_size=true a maintenant une plus grande portée (un effet plus large).

Les longueurs précédentes pour les types CHAR / VARCHAR pouvaient être vérifiées et le remplissage exécuté seulement lors de l'insertion / mise à jour de lignes. (Previously CHAR /VARCHAR lengths could be checked and padding performed only when inserting / updating rows.) Prise en charge supplémentaire de CHAR(n), VARCHAR(n), NUMERIC(p,s) et DECIMAL(p,s) incluant la sémantique des fonctions standards SQL cast et convert. Les déclarations CHAR et VARCHAR requièrent maintenant un paramètre Taille (size). Une déclaration CHAR sans paramètre size est interprété comme CHAR(1). TIMESTAMP(0) et TIMESTAMP(6) sont aussi supportés, avec une précision représentant une résolution en fraction de seconde (sub-second).

Une fonction CAST(c AS VARCHAR(2)) explicite tronquera toujours la chaîne de caractères. Une fonction CAST(n AS NUMERIC(p)) explicite exécutera toujours la conversion ou éliminera le superflu si n est en dehors des limites. (Explicit CAST(n AS NUMERIC(p)) will always perform the conversion or throw if n is out of bounds.) Toutes les autres conversions implicites et explicites de CHAR(n) et VARCHAR(n) sont assujetties aux règles du standard SQL.

Les expressions ALL et ANY

Pleine prise en charge de ALL(SELECT ....) et ANY(SELECT ....) avec les opérateurs de comparaison suivants : =, >, <, <>, >=, <=

Exemple: 

SELECT ... WHERE <value expression> >= ALL(SELECT ...)

LIMIT et OFFSET

Nouvelle syntaxe alternative pour LIMIT à la fin d'une requête : 

LIMIT L [OFFSET O]

L'utilisation de LIMIT en combinaison avec la clause ORDER BY est maintenant possible dans les sous-requêtes et déclarations SELECT entre parenthèses (brackets) faisant parties de l'UNION ou autres opérations.

Une clause ORDER BY ou LIMIT s'applique au résultat complet de l'UNION et autres opérations ou alternativement ou alternativement à l'une de ses composantes dépendant du nombre se parenthèses utilisées. Dans le premier exemple le focus (scope) est sur le second SELECT, alors que dans la seconde requête, la portée (scope) est le résultat de l'UNION. 

SELECT ... FROM ... UNION 
(SELECT ... FROM ... ORDER BY .. LIMIT)

SELECT ... FROM ... UNION 
SELECT ... FROM ... ORDER BY .. LIMIT

Prise en charge de ORDER BY, LIMIT et OFFSET dans les déclarations CREATE VIEW.


Indexations (COLLATIONS)

http://en.wikipedia.org/wiki/Collation

Chaque base de données peut avoir sa propre collation. La commande SQL ci-dessous définit la collation parmi le jeu de collations à la source de org.hsqldb.Collation : 

SET DATABASE COLLATION <Nom de collation entre guillemets>

Cette commande n'a d'effet que sur une base de données vide. Once it has been issued, the database can be opened in any JVM locale and will retain its collation.

La propriété sql.compare_in_locale=true n'est plus supportée. Si cette ligne existe dans un fichier .properties, elle basculera la base de données vers la collation pour l'option par défaut courante.


Résolution de nom dans les requêtes

(See Parsing in Wikipedia.)

Des améliorations de Parsing permettent que des mots réservés SQL puissent être utilisés comme identifiants quand ils sont entre guillemets, et donc servir dans des requêtes. Par exemple : 

CREATE TABLE "TABLE" ("INTEGER" INTEGER)

Améliorations du traitement des alias de colonnes et de tables dans les conditions des requêtes.

Améliorations

Depuis la version 1.7.3, l'évaluation des expressions booléennes a changé pour se conformer aux standards SQL. Toute expression BOOLEAN peut être TRUE, FALSE, ou UNDEFINED. Le résultat indéfini est l'équivalent de NULL.

Changement optionnel du comportement des transactions dans le mode par défaut READ UNCOMMITTED. Quand la propriété de la base de données sql.tx_no_multi_write=true a été définie, une transaction ne peut plus supprimer ou mettre à jour une ligne qui a déjà été mise à jour ou ajoutée par une autre transaction non validée (uncommitted).

Support d'un forçage de type (casting) de TIME en TIMESTAMP, par l'utilisation de CURRENT_DATE

Réparations de bogues

  • Avec NOT LIKE et les valeurs nulles.
  • Avec les conditions OR dans les jointures externes. (OUTER JOIN)
  • Avec la fermeture dupliquée des déclarations préparées. (prepared statements)

Réparation de diverses anomalies de parsing où les commandes SQL étaient acceptées entre apostrophes, entre guillemets ou préfixées par un identificateur, ou les identificateurs étaient acceptés entre apostrophes. Exemple d'une commande qui n'est plus maintenant tolérée :

Requête malformée
MY. "SELECT" ID FROM 'CUSTOMER' IF.WHERE ID=0;
Requête actuelle
SELECT ID FROM CUSTOMER WHERE ID=0;
  • Problème réglé avec les noms d'utilisateur illégaux.
  • Réparation dans l'implémentation de la table TEXT pour maintenir le statut validé des lignes durant le processus de récupération suivant un arrêt impromptu. Les changements non validés n'apparaîtront pas dans les tables TEXT.

Amélioration du stockage et de la persistance

Nouvelle propriété de connexion pour le réglage de type de table par défaut lors de l'utilisation de CREATE TABLE. La propriété de connexion hsqldb.default_table_type=cached assignera la valeur par défaut à CACHED. La commande SET PROPERTY peut également être utilisée. Les valeurs permises sont "cached" et "memory".

Support amélioré des tables texte. Le support dans la nouvelle ligne de champs entre apostrophes est maintenant terminé. (Newline support in quoted fields is now complete.) Il est maintenant possible de sauver et recharger la première ligne de titre d'un fichier CSV avec ignore_first=true. Lors de la création d'une table texte avec un nouveau fichier source (CSV) et si ignore_first=true a été spécifié alors la commande suivante peut permettre d'établir une chaîne de caractères définie par l'utilisateur comme première ligne : 

SET TABLE <NomDeTable> SOURCE HEADER <Chaîne entre guillemets>.

Une nouvelle application journal (application log) a vu le jour en tant qu'option. Utilisez la paire propriété/valeur "hsqldb.applog=1" dans la première chaîne de connexion pour journaliser des messages importants. La valeur par défaut est "hsqldb.applog=0", qui signifie "pas d'historique". Un nouveau fichier terminant par ".app.log" est généré à coté des autres fichiers de la base de données pour cette option.

Dans la version en cours, seulement les classes utilisées pour la persistance du fichier, plus chaque erreur rencontrée lors du traitement du fichier .log suite à un arrêt anormal sont journalisées.

Veuillez noter que le pilote JDBC et le moteur de la 1.8.0 ne peuvent être mélangés avec ceux des versions précédentes dans le paramétrage client/serveur. Vérifiez les chemins de vos classes et utilisez la même version du moteur pour le client et le serveur.

Introduction d'une nouvelle propriété pour repousser les limites des plus grands fichiers de données. Une fois paramétrée, la limite maximum est maintenant de 8 Go. Cette propriété se paramètre par la commande SQL suivante seulement quand la base de données ne possède aucune table (nouvelle base de données) : 

SET PROPERTY "hsqldb.cache_file_scale" 8

Pour appliquer le changement à une base de données existante, il faut appliquer d'abord SHUTDOWN SCRIPT, et la ligne propriété=valeur ci dessous doit être ajoutée au fichier .properties avant réouverture de la base de données : 

hsqldb.cache_file_scale=8

Une nouvelle propriété permet à CHECKPOINT DEFRAG d'être exécuté automatiquement soit si le moteur (en interne) effectue un CHECKPOINT ou via une commande utilisateur : 

SET CHECKPOINT DEFRAG n

Le paramètre n est le nombre de mégaoctets d'espace inutilisé (abandonné) dans le fichier .data. Lors de l'exécution d'un CHECKPOINT, (soit parce que le fichier .log atteint la limite définie par "SET LOGSIZE m", ou parce que l'utilisateur envoie une commande CHECKPOINT) la taille de l'espace abandonné durant la session est vérifiée et si elle est plus grande que n, un CHECKPOINT DEFRAG est exécuté au lieu du simple CHECKPOINT.

Réécriture du log et du cache de manipulation des classes, dont :

  • Nouveau gestionnaire de délétion des blocs doté d'une réutilisation des blocs supprimés plus efficiente.
  • Processus de journalisation (log) plus rapide suite à un arrêt anormal.
  • Meilleures vérifications quand la taille maximum d'un fichier de données est atteinte.
  • Meilleure récupération quand la taille maximum d'un fichier de données est atteinte.

La prise en charge du protocole de connexion res: (fichiers de base de données dans une jar) a été étendue pour permettre les tables CACHED.

JDBC et autres améliorations

ResultSetMetaData délivre une précision/échelle identique dans les deux modes intégré et client/serveur.

Quand on utilise PreparedStatement.setTimestamp() et ResultSet.getTimestamp() avec un paramètre de calendrier, le résultat est identique (symmetrical) si les zones de temps sont les mêmes.

Ajout d'une méthode publique shutdown() au serveur.

Améliorations dans DatabaseManagerSwing et SqlTool.

Réparation de bogue

Lors d'un passage entre deux index, causant des résultats faux dans certaines requêtes et dans les circonstances suivantes :

  • CREATE TABLE est exécuté.
  • Utilisation de ALTER TABLE ADD FOREIGN KEY pour créer une clé externe sur une table différente de celle déjà présente quand la première commande a été initiée. (is used to create an FK on a different table that was already present when the first command was issued.)
  • Utilisation de CREATE INDEX pour ajouter un index.
  • Les données sont ajoutées à la table.
  • Fermeture de la base de données.
  • Redémarrage de la base de données.

A ce moment les index sont inactifs (switched) et les requêtes utilisant l'un ou l'autre de ces index ne retourneront pas le bon jeu de lignes. Ifst command was issued.

  • Utilisation de CREATE INDEX pour ajouter un index.
  • Les données sont ajoutées à la table.
  • Fermeture de la base de données.
  • Redémarrage de la base de données.

A ce moment les index sont inactifs (switched) et les requêtes utilisant l'un ou l'autre de ces index ne retourneront pas le bon jeu de lignes. Si aucune donnée n'a été ajoutée avant la première fermeture, la base de données fonctionnera normalement.

Mettre à jour les bases de données

Les base de données qui ne contiennent pas de tables CACHED peuvent être ouvertes avec la nouvelle version. Pour les bases de données munies de tables CACHED qui ont été créées avec les versions 1.7.2 ou 1.7.3, la commande SHUTDOWN SCRIPT doit être exécutée une fois sur la base de données avant de l'ouvrir avec la nouvelle version. Si les bases de données ont été créées avec des versions antérieures, vous devez suivre les instructions dans la section "Considérations avancées" de ce guide.

Intégration dans Apache OpenOffice

Lors de l'utilisation de Apache OpenOffice comme base de données par défaut, plusieurs valeurs par défaut et propriétés sont automatiquement définies :

  • CREATE TABLE ... La valeur par défaut est CREATE CACHED TABLE ...
  • hsqldb.cache_scale=13
  • hsqldb.cache_size_scale=8
  • hsqldb.log_size=10
  • SET WRITE DELAY 2
  • sql.enforce_strict_size=true
Retrieved from "https://wiki.openoffice.org/w/index.php?title=FR/Documentation/HSQLDB_Guide/ChangeLog1.8.0&oldid=124513"
Personal tools