asfernandes
Firebird, Wicket, Java, C++, Linux and something else

Na parte de expressões SQL, o Firebird 2.5 acrescenta melhorias e novidades. A função agregada LIST (presente desde a versão 2.1) agora aceita qualquer expressão em seu segundo parâmetro, onde o desenvolvedor pode especificar a string de separação dos elementos retornados. Até a versão 2.1.3 era possível apenas o uso de strings constantes nesse parâmetro. Nota: a versão 2.1.4 também deve ser liberada com esta novidade. A listagem 10 mostra a utilidade deste parâmetro, principalmente no desenvolvimento de relatórios, agrupando várias mensagens referentes a um documento em um mesmo registro e mostrando cada mensagem em uma linha.

Listagem 10. Usando a função LIST com expressões no segundo parâmetro.

SELECT LIST(MENSAGEM, ASCII_CHAR(13) || ASCII_CHAR(10))
 FROM MENSAGENS_DOCUMENTO WHERE DOCUMENTO = 10;

Referente a parâmetros de comandos SQL, o Firebird suporta apenas o uso de parâmetros anônimos com o símbolo “?” (ponto de interrogação). Algumas bibliotecas (inclusive de Delphi) aceitam o uso de parâmetros nomeados usando “:” (dois pontos). Quando o desenvolvedor tentava escrever queries usando o padrão [WHERE :CODIGO IS NULL OR CODIGO = :CODIGO] para trazer todos os registros quando o parâmetro não fosse informado, o Firebird retornava um erro. Isto porque este comando é traduzido pelas bibliotecas para [WHERE ? IS NULL OR CODIGO = ?] e o Firebird não aceitava o uso de parâmetro com o predicado IS NULL, pois o tipo do parâmetro era considerado como desconhecido. Na versão 2.5 foi adicionado à API o tipo SQL_NULL. As bibliotecas de acesso precisam entender este novo tipo e apenas passar se o valor do parâmetro é ou não NULL, permitindo assim o uso deste padrão de comando.

Outra novidade referente a expressões é o novo predicado SIMILAR TO. Esta expressão é usada para fazer comparações usando expressões regulares de acordo com o padrão SQL. A listagem 11 mostra uma verificação de números de telefones cadastrados fora do padrão (NN) NNNN-NNNN. O caractere de escape funciona exatamente como no comando LIKE, considerando o próximo caractere como um valor literal, ao invés de usá-lo como um operador.

Listagem 11. Verificando números de telefones cadastrados fora do padrão.
SELECT * FROM PESSOAS
 WHERE TELEFONE NOT SIMILAR TO
   '\([0-9]{2}\) [0-9]{4}\-[0-9]{4}' escape '\'
A tabela 1 mostra os operadores permitidos em expressões regulares e a tabela 2 mostra as classes de caracteres que podem ser usadas com o operador [[:CLASSE:]].


Operador
Descrição
X{2}
Duas ocorrências de X.
X{2,}
Duas ou mais ocorrências de X.
X{4,6}
De quatro a seis ocorrências de X.
X?
Zero ou uma ocorrência de X.
X*
Zero ou mais ocorrências de X.
X+
Uma ou mais ocorrências de X.
X|Y
X ou Y.
_
Qualquer caractere - como no LIKE.
%
Qualquer sequência de caracteres - como no LIKE.
(X)
Agrupa X para ser tratado pelo operador subsequente.
[XYZ]
Qualquer caractere igual a X, Y ou Z.
[^XYZ]
Qualquer caractere diferente de X, Y ou Z.
[X-Z]
Qualquer caractere entre X e Z.
[[:CLASSE:]]
Qualquer caractere de uma certa classe, conforme tabela 2.
Tabela 1. Operadores de expressões regulares.


Classe
Descrição
ALPHA
Qualquer caractere entre A e Z.
UPPER
Qualquer caractere maiúsculo.
LOWER
Qualquer caractere minúsculo.
DIGIT
Dígitos de 0 a 9.
SPACE
Espaço: caractere (ASCII_CHAR) 32.
WHITESPACE
Todo tipo de espaço: caracteres 9, 10, 11, 12, 13 e 32.
Tabela 2. Classes de caracteres para expressões regulares.


O Firebird 2.5 também suporta novos formatos de valores literais (constantes) para números e strings. Agora é possível escrever números inteiros no formato hexadecimal, usando o prefixo 0x. Quando o número possuir até 8 dígitos hexadecimais após o 0x, como em 0xFFFFFFFF, o número adquire o tipo INTEGER (32 bits com sinal). Quando possuir mais de 8 dígitos, como em 0x0FFFFFFFF, o tipo adquirido é o BIGINT (64 bits com sinal). Desta forma, estas duas constantes retornam valores diferentes, pois os números negativos são armazenados na notação complemento de dois [1].

Além de números, também é possível a criação de strings binárias (character set OCTETS) usando a notação hexadecimal x''. Em ambos os casos a letra X pode ser escrita em maiúscula ou minúscula. A listagem 12 mostra o uso destes novos tipos de valores literais. Note que cada par de caracteres hexadecimais se transforma em um byte na string resultante.

Listagem 12. Novos formatos de expressões literais.
SELECT 0xDEADBEEF, x'DEADBEEF' FROM RDB$DATABASE;
SELECT OCTET_LENGTH(x'DEADBEEF') FROM RDB$DATABASE;
-- Resultado de OCTET_LENGTH: 4, e não 8

A nova função BIN_NOT se junta ao grupo de funções binárias adicionadas na versão 2.1, BIN_AND e BIN_OR. Junto com as constantes hexadecimais, essa família de funções facilita o uso de máscaras de valores binários gravados em um único campo, técnica comumente utilizada em aplicações e agora facilitada no banco de dados. A listagem 13 mostra o uso da função BIN_NOT, que inverte todos os bits de um valor inteiro.

Listagem 13. Exemplo de uso da função BIN_NOT.
SELECT BIN_NOT(0xFFFFFFFF) FROM RDB$DATABASE;  -– Resultado: 0

Na versão 2.1 foi adicionada a função GEN_UUID, que retorna um UUID [2] como um valor do tipo CHAR(16) CHARACTER SET OCTETS. Este tipo de retorno foi escolhido pois é a representação mais compacta para ser usado em índices, porém requer suporte das aplicações que desejam exibir estes UUIDs aos usuários. Na nova versão foram adicionadas funções para conversão entre as representações binária e texto [CHAR(36) CHARACTER SET ASCII] de UUIDs, as funções CHAR_TO_UUID e UUID_TO_CHAR. O formato texto de UUID aceito e retornado por estas funções é 'XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX'. A listagem 14 mostra o uso destas funções.


Listagem 14. Exemplo de uso das funções UUID_TO_CHAR e CHAR_TO_UUID.
SELECT UUID_TO_CHAR(UUID), DESCRICAO FROM OBJETOS

 WHERE UUID = CHAR_TO_UUID(?);


Notas

[1] - Complemento de dois é a notação mais comum usada para representar números inteiros com sinal em sistemas computacionais. Nesta notação o bit mais significativo de um número positivo ou do número zero é representado como 0. Os números negativos são representados com os bits invertidos e somado o valor 1. Desta forma, em um número de 32 bits o 1 é representado com trinta e um bits 0 seguido por um bit 1, enquanto que o número -1 é representado por trinta e dois bits 1.

[2] - UUID (Universally Unique Identifier) é uma sequência aleatória de 16 bytes que, independente do local e momento que seja gerada, é única. Uma das utilidades dos UUIDs é criar chaves em sistemas distribuídos, como filiais de uma empresa com bancos de dados separados e que tenham os dados agregados em um banco principal através de replicação.

 

Artigo "Novidades do Firebird 2.5": Comandos DDL

Posted In: , . By Adriano dos Santos Fernandes

Além do comando CREATE COLLATION, mostrado na seção anterior, o Firebird 2.5 acrescenta comandos DDL que aliviam limitações anteriores e outros comandos totalmente novos. Duas limitações existentes nas versões anteriores eram relacionadas à impossibilidade de alteração de colunas COMPUTED BY e views. Era preciso eliminar estes objetos e recriá-los com as alterações. O problema é que o Firebird não permite que um objeto seja eliminado quando este está sendo usado por outro objeto. Algumas ferramentas (como o Flamerobin, por exemplo) geram scripts para eliminar e recriar objetos durante a alteração de um objeto que não era permitida, porém esta não é a solução ideal.

A listagem 5 mostra o comando usado para alteração de uma expressão COMPUTED no Firebird 2.5 e a listagem 6 mostra um exemplo do comando ALTER VIEW.

Listagem 5. Exemplo de alteração de expressão COMPUTED BY.
-- Criação da tabela com erro na expressão da coluna IDADE.
CREATE TABLE PESSOAS (
 NOME VARCHAR(60),
 DATA_NASCIMENTO DATE,
 IDADE COMPUTED BY (DATEDIFF(YEAR, CURRENT_DATE, DATA_NASCIMENTO)));
INSERT INTO PESSOAS VALUES ('Fulano', '2000-01-01');
INSERT INTO PESSOAS VALUES ('Beltrano', '1950-05-10');
SELECT * FROM PESSOAS;  -- Lista a idade como negativa.
-- Correção da expressão da coluna IDADE.
ALTER TABLE PESSOAS
 ALTER IDADE COMPUTED BY (DATEDIFF(YEAR, DATA_NASCIMENTO, CURRENT_DATE));
SELECT * FROM PESSOAS;

Listagem 6. Exemplo do comando ALTER VIEW.
-- View criada incorretamente sem a expressão WHERE.
CREATE VIEW PESSOAS_MAIORES AS
 SELECT * FROM PESSOAS;
-- Correção da view.
ALTER VIEW PESSOAS_MAIORES AS
 SELECT * FROM PESSOAS WHERE IDADE >= 18;

Assim como em outros comandos DDL, também é permitido o uso dos comandos RECREATE VIEW e CREATE OR ALTER VIEW. Além dos novos comandos relacionados a views, agora é permitido o uso de stored procedures na cláusula FROM de uma view, o que não era permitido nas versões anteriores. A listagem 7 mostra um exemplo.


Listagem 7. Exemplo de uso de stored procedure em uma view.
SET TERM !;
CREATE PROCEDURE PESSOAS_SP RETURNS (NOME VARCHAR(60), IDADE INTEGER) AS
BEGIN
 FOR SELECT NOME, IDADE FROM PESSOAS INTO NOME, IDADE DO
     SUSPEND;
END!
SET TERM ;!
CREATE VIEW PESSOAS_SP_MAIORES AS
 SELECT * FROM PESSOAS_SP WHERE IDADE >= 18;

Na nova versão também foram incluídos comandos DDL para manuseio do banco de dados de usuários. Estes comandos são: CREATE USER, ALTER USER e DROP USER. Estes comandos podem ser executados quando conectado a qualquer banco de dados, mas sempre atualizam os dados do banco de dados geral de usuários (security2.fdb). Os comandos CREATE USER e DROP USER podem ser usados apenas por usuários com privilégio de administrador. O comando ALTER USER pode ser usado por qualquer usuário, desde que usado para alterar apenas suas próprias informações (a senha, por exemplo). Já os administradores podem usar ALTER USER para alterar informações de qualquer usuário. Além da senha (PASSWORD), é possível registrar os nomes (FIRSTNAME, MIDDLENAME e LASTNAME) e definir se um usuário é ou não um administrador com a cláusula GRANT/REVOKE ADMIN ROLE. A listagem 8 mostra exemplos de criação, alteração e remoção de usuários.


Listagem 8. Manuseio do banco de dados de segurança com comandos SQL.
CREATE USER FULANO PASSWORD 'altereja'
 FIRSTNAME 'Fulano' LASTNAME 'da Silva';
ALTER USER SYSDBA PASSWORD 'masterkey';
DROP USER BELTRANO;
CREATE USER ADMIN_ADJUNTO PASSWORD 'masterkey' GRANT ADMIN ROLE;
GRANT RDB$ADMIN TO ADMIN_ADJUNTO;

Para um usuário tornar-se efetivamente um administrador, um usuário que já seja administrador (como o SYSDBA) precisa, além de colocar GRANT ADMIN ROLE no CREATE USER ou ALTER USER, conceder a role RDB$ADMIN ao usuário com o comando “GRANT RDB$ADMIN TO Usuario” em cada banco de dados que o usuário poderá atuar como administrador. O usuário também precisará conectar-se ao banco de dados usando a ROLE RDB$ADMIN. A listagem 9 mostra o usuário ADMIN_ADJUNTO atuando como SYSDBA.


Listagem 9. Conectando-se com privilégios de administrador a um banco de dados.
CONNECT 'TEST.FDB' USER ADMIN_ADJUNTO
 PASSWORD 'masterkey' ROLE RDB$ADMIN;

DROP USER FULANO;

 

Artigo "Novidades do Firebird 2.5": Character Sets e Collates

Posted In: , . By Adriano dos Santos Fernandes

No Firebird, diferentes tabelas ou até mesmo diferentes colunas de uma mesma tabela podem usar diferentes character sets e collates. Isto permite uma grande flexibilidade mas pode causar problemas caso o desenvolvedor ou DBA não se atente às necessidades da aplicação. Por isso, um banco de dados pode ter um character set default, que é automaticamente usado quando não é especificado um character set durante a definição de uma coluna de tipo string. Algo semelhante não existia para collates, sendo que o collate default de cada character set é o modo de comparação binária dos bytes que compõem uma string.

Na nova versão foi introduzido o comando ALTER CHARACTER SET, permitindo a alteração do collate padrão de um character set. Além do comando ALTER CHARACTER SET, agora o collate padrão do character set padrão do banco pode ser definido no momento da criação do banco de dados. A listagem 1 mostra a criação de um banco de dados usando o character set padrão WIN1252 e definindo seu collate padrão para WIN_PTBR. Em seguida o collate padrão do character set UTF8 é alterado para UNICODE_CI_AI.


Listagem 1. Exemplos de alteração de collate padrão.

CREATE DATABASE 'TEST.FDB'
  DEFAULT CHARACTER SET WIN1252
  COLLATION WIN_PTBR;

ALTER CHARACTER SET UTF8
  SET DEFAULT COLLATION UNICODE_CI_AI;



A listagem 2 mostra o banco operando com o character set default WIN1252 e o collate WIN_PTBR (case-insensitive).

Listagem 2. Comparação de strings usando o collate WIN_PTBR.

CREATE TABLE PESSOAS (NOME VARCHAR(20));

INSERT INTO PESSOAS VALUES ('Fulano');
INSERT INTO PESSOAS VALUES ('Beltrano');

-- Localiza Fulano (= FULANO)
SELECT * FROM PESSOAS WHERE NOME = 'FULANO';


Outra necessidade comumente encontrada em aplicações é a gravação de códigos alfanuméricos. Até o Firebird 2.1 a ordenação de campos do tipo string era sempre feita no modo de comparação de texto. Isto quer dizer que um código “A10” é listado antes de “A2” caso ordenado por esta coluna. A listagem 3 mostra um exemplo desta situação.

Listagem 3. Ordenação de códigos alfanuméricos usando o collate UNICODE.

CREATE TABLE DOCUMENTOS (
  CODIGO VARCHAR(10) CHARACTER SET UTF8 COLLATE UNICODE
);

INSERT INTO DOCUMENTOS VALUES ('A1');
INSERT INTO DOCUMENTOS VALUES ('A2');
INSERT INTO DOCUMENTOS VALUES ('A10');
INSERT INTO DOCUMENTOS VALUES ('A11');
INSERT INTO DOCUMENTOS VALUES ('A100');
INSERT INTO DOCUMENTOS VALUES ('B1');
INSERT INTO DOCUMENTOS VALUES ('B10');

-- Resultado: A1, A10, A100, A11, A2, B1, B10
SELECT CODIGO FROM DOCUMENTOS ORDER BY CODIGO;



O Firebird 2.5 permite que collates sejam configuráveis, e uma das opções do collate UNICODE permite que números sejam ordenados por ordem numérica. A listagem 4 mostra a criação do collate UNICODE_NUM com o uso da opção NUMERIC-SORT e a ordenação usando este collate.

Listagem 4. Ordenação usando a opção NUMERIC-SORT do collate UNICODE.

CREATE COLLATION UNICODE_NUM FOR UTF8 FROM UNICODE 'NUMERIC-SORT=1';

CREATE TABLE DOCUMENTOS2 (
  CODIGO VARCHAR(10) CHARACTER SET UTF8 COLLATE UNICODE_NUM
);

INSERT INTO DOCUMENTOS2 SELECT * FROM DOCUMENTOS;

-- Resultado: A1, A2, A10, A11, A100, B1, B10
SELECT CODIGO FROM DOCUMENTOS2 ORDER BY CODIGO;



Outra novidade da versão 2.5 é o collate UNICODE_CI_AI (para o character set UTF8), variação do collate UNICODE pré-configurado para desconsiderar diferenças de acentos e maiúsculas/minúsculas. O collate UNICODE_CI_AI funciona de maneira similar ao WIN_PTBR e PT_BR, mas aceita o conjunto completo de caracteres Unicode.

 

Artigo "Novidades do Firebird 2.5": A arquitetura SuperClassic

Posted In: , . By Adriano dos Santos Fernandes

Desde sua primeira versão, o Firebird foi disponibilizado em dois modos de operação (chamados de arquiteturas) diferentes, a SuperServer e a Classic. Na SuperServer as conexões aos bancos de dados são gerenciadas com múltiplas threads em um único processo do SO, enquanto que na Classic é aberto um processo para cada conexão realizada.

A vantagem da arquitetura SuperServer é que diversas conexões a um mesmo banco de dados são gerenciadas com apenas um cache de dados e metadados. Sua desvantagem é que, internamente, a execução de queries é feita de maneira cooperativa, isto é, em determinados pontos uma query paralisa sua própria execução e passa o controle para que outra query continue executando, não aproveitando adequadamente os recursos de máquinas com mais de um processador ou núcleo. Nota: O time de desenvolvedores do Firebird trabalha para remover completamente esta limitação na versão 3, e a SuperClassic é o primeiro passo em busca desse objetivo. Outra desvantagem da SuperServer é que apenas um processo pode abrir cada banco de dados. Isto causava uma limitação em aplicativos que usavam a biblioteca Embedded, como veremos mais adiante.

Na arquitetura Classic cada processo pode executar queries paralelamente, de forma preemptiva, porém cada um possui seu exclusivo cache. Para manter a integridade, o Firebird precisa realizar comunicação inter-processo através de seu lock manager. Essa comunicação causa uma perda de desempenho em relação à SuperServer. Nesta arquitetura também existia a possibilidade de trabalhar com diversas conexões em apenas um processo, porém com a mesma limitação presente na SuperServer, onde as queries de um mesmo processo rodavam de maneira cooperativa. Além disso, esta possibilidade existia apenas com a versão Embedded para Linux, pois rodando no modo servidor a criação de novos processos era sempre feita automaticamente a cada conexão.

O novo modo SuperClassic é uma mistura das duas arquiteturas preexistentes. Um processo SuperClassic pode gerenciar diversas conexões usando threads, como no SuperServer. Mas, diferentemente do SuperServer, cada conexão possui seu cache exclusivo, como no Classic. Como o cache não é compartilhado, as queries podem rodar de maneira preemptiva, melhorando o desempenho em máquinas multiprocessadas.

A arquitetura SuperServer também teve uma melhoria. Até a versão 2.1 as queries eram sincronizadas por servidor, e na versão 2.5 são sincronizadas por banco de dados. Isto significa que um servidor 2.5 gerenciando conexões a vários bancos de dados aproveitará os recursos de hardware de forma mais satisfatória.

Além de SuperServer e Classic, o Firebird também é disponibilizado como uma biblioteca: a versão Embedded. Até a versão 2.1 a biblioteca Embedded trabalhava no modo SuperServer no ambiente Windows e no modo Classic em outros SOs. Na versão 2.5 a biblioteca Embedded usa o modo SuperClassic em todos os SOs. Como o SuperClassic é o Classic melhorado, tornou-se possível o acesso simultâneo a um banco de dados por diversos aplicativos usando a biblioteca Embedded, removendo esta limitação que existia em ambientes Windows. Nota: o compartilhamento de um banco de dados em vários processos Classic (ou Embedded) é permitido apenas quando todos os processos sejam da mesma arquitetura, 32 ou 64 bits. Com a mudança de arquitetura da versão Embedded, o desenvolvedor precisa verificar se o desempenho de seu aplicativo foi influenciado negativamente, pois a configuração padrão de buffers dos bancos de dados são diferentes nas duas arquiteturas. Esta configuração pode ser ajustada alterando-se o valor do parâmetro DefaultDbCachePages no arquivo firebird.conf ou com o comando gfix -buffers em cada banco de dados.

 

Conforme citado na introdução, a compatibilidade é levada a sério no Firebird. Infelizmente, porém, às vezes é preciso fazer mudanças que causam certas dificuldades de migração. Antes da versão 2.1 o Firebird tinha importantes bugs referentes a implementação de character sets multibyte herdados do InterBase. Um destes character sets é o UNICODE_FSS, que é usado pelas tabelas de sistema RDB$. O Firebird não convertia, do character set cliente para o UNICODE_FSS, nomes, strings e código fonte de objetos durante a execução de comandos DDL e simplesmente gravava os dados, que do ponto de vista do UNICODE_FSS eram inválidos. A partir da versão 2.1 esta conversão passou a ser feita, embora ainda fosse possível a criação de objetos inválidos usando o character set NONE. Para corrigir os objetos gravados de forma incorreta, foi disponibilizado um script que deveria ser rodado após o restore na versão 2.1.

A partir da versão 2.5 o Firebird passou a recusar dados e metadados inválidos com o character set UNICODE_FSS. Isto significaria que qualquer banco de dados de versões anteriores que tivesse problemas de character set não poderia ser restaurado na nova versão. Diante dessa situação, foram acrescentadas duas opções ao gbak, para serem usadas durante o processo de restauração e corrigir este tipo de problema.

A opção -FIX_FSS_METADATA seguida do nome de um character set é usada para informar em que character set foram criados os objetos de banco de dados presentes no backup. Durante a restauração os metadados são convertidos deste character set para o UNICODE_FSS e gravados corretamente.

A outra opção, -FIX_FSS_DATA seguida do nome de um character set, deve ser usada apenas em bancos de dados que tenham tabelas de usuários criadas usando o character set UNICODE_FSS. Esta opção realiza a conversão dos dados da mesma forma que -FIX_FSS_METADATA realiza a conversão dos metadados.

O uso destas opções só é necessário caso o banco possua metadados e dados com caracteres fora do padrão ASCII, como caracteres acentuados, por exemplo. É recomendado que se tente inicialmente fazer a restauração sem usar estas opções. Se o processo falhar por estes problemas, será mostrada uma mensagem de erro recomendando o uso. Para usar o character set correto nestas opções, o usuário precisa ter um conhecimento mínimo sobre character sets (ou páginas de códigos de caracteres) e dos sistemas operacionais usados pelas aplicações cliente. Por exemplo, aplicações que executavam comandos DDL pelo Windows (configurado para Português/Brasil) devem usar WIN1252. Já no Linux a maioria das distribuições atuais trabalha com UTF-8, que é compatível com UNICODE_FSS e não deveria causar problemas.

Estas opções podem não resolver os problemas caso o banco de dados tenha dados ou metadados gravados de forma incorreta usando diferentes character sets. Neste caso será necessário corrigir os problemas com o auxílio dos scripts de migração usando a versão 2.1.

Após a migração do banco de dados, o desenvolvedor precisa se certificar que seus aplicativos conectam-se ao banco usando o client character set correto. O uso do character set NONE (padrão) ou de um character set incorreto podem causar erros de “malformed string” e “transliteration exception”.

 

Artigo "Novidades do Firebird 2.5": Introdução

Posted In: , . By Adriano dos Santos Fernandes

O desenvolvimento do SGBD Firebird foi iniciado em Julho do ano 2000 a partir do código fonte da versão beta do InterBase 6.0, disponibilizado pela Inprise (Borland) sob licença open source. Desde então cinco versões foram lançadas pela sua equipe de desenvolvimento, mostrando uma evolução contínua do produto. O foco deste artigo é mostrar as principais funcionalidades para desenvolvedores adicionadas à versão 2.5, lançada em outubro de 2010, no ano em que o projeto faz seu décimo aniversário. Antes de aprofundar nestes temas, gostaria de mostrar um breve histórico da evolução do Firebird nestes dez anos.

Na versão 1.0 a maior parte do trabalho foi interna, já que o código inicial não tinha documentação e não chegava nem mesmo a compilar. Uma das alterações mais importantes nesta versão foi a correção de um bug de segurança do InterBase, que foi rapidamente identificado quando seu código tornou-se público.

Na versão 1.5 o código fonte foi convertido de C para C++. Algumas novidades que apareceram nesta versão foram variáveis de contexto como CURRENT_USER e CURRENT_ROLE, funções como COALESCE e NULLIF, expressões CASE, o tipo de dados BIGINT, melhorias em alguns comandos DDL (CREATE OR ALTER, RECREATE), o comando EXECUTE STATEMENT, as cláusulas FIRST e SKIP e suporte a savepoints e locks pessimistas.

A versão 2.0 introduziu as tabelas derivadas [1], cursores explícitos, valores default para parâmetros, as funções IIF, CHAR_LENGTH, TRIM, RDB$GET_CONTEXT e RDB$SET_CONTEXT, o operador IS [NOT] DISTINCT, os comandos EXECUTE BLOCK e COMMENT ON, a cláusula RETURNING, índices definidos por expressões, collates (PT_BR e WIN_PTBR) para o Brasil, suporte a Unicode, melhorias de performance relacionadas à nova implementação de índices e diversas mudanças no otimizador, backups físicos e incrementais com o NBackup e suporte a plataformas 64-bit.

A versão 2.1 introduziu dezenas de novas funções internas, triggers de eventos de conexão e transação, tabelas temporárias, collates customizáveis com CREATE COLLATION, queries recursivas com Common Table Expression (CTE) [2], os comandos UPDATE OR INSERT e MERGE, a função agregada LIST, a possibilidade de uso de domains em PSQL, a interoperabilidade entre BLOBs e strings, tabelas de monitoração, o utilitário fbsvcmgr e diversas melhorias implementadas no protocolo de comunicação, melhorando a performance de comunicação cliente/servidor via internet.

Diante de toda essa evolução, é importante ressaltar que toda alteração e nova funcionalidade do Firebird é pensada levando em consideração dois princípios estabelecidos pelo projeto: compatibilidade e padronização SQL. A compatibilidade é sempre levada extremamente a sério, e dificilmente algo que funciona em uma versão deixa de funcionar em outra, respeitando o investimento feito pelos desenvolvedores. Em relação ao padrão SQL, ele é sempre consultado e analisado em detalhes, e quando possível, as implementações são realizadas com base neste padrão.

A versão 2.5, assim como as anteriores, possui diversas novas funcionalidades. Primeiramente, veremos sobre possíveis problemas durante o processo de migração. Em seguida, veremos sobre a nova arquitetura SuperClassic, que permite melhor aproveitamento de recursos e melhor desempenho em máquinas multiprocessadas, e as alterações diretamente relacionadas ao desenvolvimento. Os exemplos presentes nas listagem foram feitos para o ISQL, mas devem funcionar sem problemas em qualquer ferramenta.

Notas

[1] - Tabela derivada (derived table) é o nome dado pelo padrão SQL a uma query usada na claúsula FROM de outra query. Por exemplo: SELECT X.* FROM (SELECT * FROM PESSOA) X. Neste caso, X é uma tabela derivada. Veja mais exemplos no release notes da versão 2.0.

[2] - Common Table Expression (CTE) é similar as tabelas derivadas, mas o nome da tabela é definido no começo da instrução com a cláusula WITH. Exemplo: WITH X AS (SELECT * FROM PESSOA) SELECT * FROM X. Com as CTEs é possível fazer queries hierárquicas (recursivas) usando-se WITH RECURSIVE e UNION ALL. Veja mais exemplos no release notes da versão 2.1.

 

Artigo "Novidades do Firebird 2.5"

Posted In: , . By Adriano dos Santos Fernandes

A partir de sexta-feira, dia 20/12/2013, começarei a postar o artigo que escrevi para a revista ClubeDelphi. Esse artigo saiu na edição #125 da revista, em dezembro de 2010.

O artigo será postado em partes, conforme abaixo:

- Introdução
- Migrando de versões anteriores
- A arquitetura SuperClassic
- Character Sets e Collates
- Comandos DDL (Data Definition Language)
- Expressões, literais e funções
- Linguagem PSQL
- Conclusão

 

Share it