<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.
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 AND OTHER ENHANCEMENTS
ResultSetMetaData reports identical precision/scale in embedded and client/server modes
When PreparedStatement.setTimestamp() and ResultSet.getTimestamp() are used with a Calendar parameter, the result is symmetrical if the time zones are equal.
Added public shutdown() method to Server.
Enhancements to DatabaseManagerSwing and SqlTool
BUG FIX
Fixed bug where two indexes where switched, causing wrong results in some queries in the following circumstances:
CREATE TABLE is executed.
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.
UPGRADING DATABASES
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.
OPEN OFFICE INTEGRATION
When used in OpenOffice.org as the default database, several defaults and properties are set automatically:
CREATE TABLE ... defaults to 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