Informix 11.70.xC6

This article is written in English and Portuguese
Este artigo está escrito em Inglês e Português

English Version:

As usual, I'm just reviewing the latest IBM Informix fixpack. The software was just released (yesterday, October 23). It's important to note that this fixpack is clearly on the "mature" phase of 11.70 and also that IBM is already working with selected customers on the next major release. As such, we should not expect too many news... Nevertheless, and I've been mentioning this to several customers, IBM uses the Agile methodology in Informix development. And one of the goals of this methodology is to provide new functionalities to customers as soon as possible. So, what am I saying with this mixed message? That even for a "quiet" fixpack we can find surprising new features. As usual, let's take a look at the release notes and comment on the new features section:

• Administration
• Enhancements to the OpenAdmin Tool (OAT) for Informix
  Just a version refresh for several components (Apache, PHP and PDO_INFORMIX)
• Support for the same XID for transactions on different databases
  A new parameter IFX_XA_UNIQUEXID_IN_DATABASE allows that a global (XA) transaction ID can be repeated in different databases in the same instance. Or in other words, the scope of the transaction ID can be changed from the instance to the database level. This is essentially a compatibility feature.
• Coordinating transactions within a high-availability cluster
  This is one of the surprises... A new parameter CLUSTER_TXN_SCOPE allows a DBA to define if the applications receive the COMMIT confirmation immediately or after the transaction information was propagated through the cluster (or just the current secondary server). This can be a bit confusing and some experimentation is required, but it basically avoids that an application that takes advantage of several cluster nodes hits some apparent data consistency issue caused by the asynchronous nature of the logical log propagation. It can also be useful if an application that changes data, triggers some other process that will read that same data from another node in the cluster. I would say this can be an invaluable option for future expansion of the clustering capabilities in Informix
• Easier failover configuration for Connection Managers in a high-availability cluster
  We can now specify the failover policy at the engine level by setting a new parameter HA_FOC_ORDER that will take priority over the policy specified in the connection manager(s) connected to the instance
• Application development
• Enhanced support for OUT and INOUT parameters in SPL routines
  Another surprise. For most cases and most people this will seem irrelevant. But I recall a couple of situations where I've found the lack of support for OUT/INOUT parameters in SPL a big limitation. I'd like to return to this topic in a future blog post... Time will tell...
• Additional functions for spatial data
  Enhanced compatibility with the ISO/OpenGIS standards
• Return the default values of columns
  Enhancement to the Datablade API
• SPL routines for application compatibility
  Yet another surprise. The functionality will not be a surprise for anyone participating in the vNext process (EVP), but it surely is surprising to see it in 11.7. The idea behind this is terribly simple, and I must confess I'm a big fan for this. We all know that Informix is extensible and that it's easy to create new functions in C language to implement some lacking functions. In fact I've been publishing a few examples of this. So, it's a great pleasure to see that IBM decided to do that and implement some compatibility functions in a new datablade. More specifically some well known packages called DBMS_ALERT, DBMS_LOB, DBMS_OUTPUT, DBMS_RANDOM, UTL_FILE are implemented.
  This can be a great help for anyone porting applications to Informix
• Time Series data
• Load time series data faster through a virtual table
  Performance improvement for the virtual table interface for TimeSeries containers

A few final comments:

1. During an exchange of emails with one of the product architects a few years ago, he wrote something like "we should avoid creating too many parameters... Let's try to keep it simple"
   I could not agree more with him, and seeing so many new parameters worries me a bit and reminds me of this talk. On the other hand, a parameter means control, and I like that. So I'd say they're a necessary evil. On the good side, they're normally well commented in the default ONCONFIG and the newly introduced ones tend to be dynamic.
2. If I worked in marketing, at this time I'd probably be keeping new features hidden so that I'd include them in the next major version as new stuff. It's good to see that this is not hapening and the main concern is clearly to provide value for customers ASAP
3. Please, please, please.... Let the compatibility packages be just the beginning. I cannot find any reason why functions are not implemented this way, even if it's not the fastest implementation. In most cases developers need the functionality more than the performance. And later it can be moved into the native SQL layer implementation without breaking compatibility. This cannot be a solution for some SQL constructs, but for "pure" functions I'd use it. In fact it's not new... We've seen this in publicly available bladelets

Versão Portuguesa:

Como vem sendo habitual vou rever a última release do IBM Informix. O software acabou de ser disponibilizado (ontem, 23 de Outubro). É importante notar que esta release está já na fase "madura" da versão 11.70 e também que a IBM está já a trabalhar com clientes selecionados sobre a próxima versão do produto. Como tal não deveremos esperar grandes novidades... Ainda assim, e tenho referido isto a vários clientes recentemente, a IBM utiliza a metodologia Agile no desenvolvimento do Informix. E um dos objetivos do Agile é disponibilizar novas funcionalidades aos utilizadores tão cedo quanto possível. Portanto, o que estou a querer dizer com estas ideias contraditórias? Que mesmo numa release "calma" podemos encontrar novas e surpreendentes funcionalidades. Como é costume vamos espreitar as notas da release e comentar a secção de novas funcionalidades: 

• Administração
• Melhorias no Open Admin Tool (OAT) para Informix
  Apenas o refrescamento de versões de vários componentes (Apache, PHP e PDO_INFORMIX)
  
• Suporte para o mesmo XID para transacções em bases de dados diferentes
  Um novo parâmetro IFX_XA_UNIQUEXID_IN_DATABASE permite que o identificador de uma transação global (XA) possa repetir-se em bases de dados diferentes dentro da mesma instância. Ou por outras palavras, que o alcance de um identificador de transação possa ser alterado da instância para o nível da base de dados. É essencialmente uma funcionalidade para melhorar a compatibilidade com ferramentas externas
  
• Coordenação de transações dentro de um cluster de alta disponibilidade
  Esta é uma das surpresas... Um novo parâmetro (CLUSTER_TXN_SCOPE) permite definir se a aplicação recebe a confirmação de um COMIIT imediatamente ou depois de a transação se propagar pelo cluster. (ou apenas para o nó secundário corrente). Isto pode parecer um pouco confuso e é necessária alguma experiência, mas basicamente evita que uma aplicação que tire proveito de vários nós do cluster encontre alguma aparente inconsistência de dados, causada pela natureza assíncrona da propagação dos logical logs. Pode ser também útil se uma aplicação que altere dados, despolete depois outro processo que vá ler esses mesmos dados em outro nó do cluster. Diria que isto pode ser uma opção de muito valor para as futuras expansões de funcionalidade de clustering do Informix
• Mais fácil configuração de failover para os Connection Managers num cluster de alta disponibilidade
  Podemos especificar a política de failover ao nível do motor através de um novo parâmetro (HA_FOC_ORDER) que terá prioridade sobre o que for especificado na configuração do Connection Manager(s) ligado(s) à instância
• Desenvolvimento aplicacional
  
• Melhoria no suporte a parâmetros OUT e INOUT nos procedimentos/funções em SPL
  Mais uma surpresa. Na maioria dos casos e para a maioria das pessoas isto parecerá irrelevante. Mas lembro-me de um par de situações onde a falta de suporte a parâmetros OUT/INOUT foi uma grande limitação. Gostaria de retornar ao tema num próximo artigo... O tempo o dirá...
• Mais funções para dados spatial
  Melhoria na compatibilidade com os standards  ISO/OpenGIS
• Retornar os valores por omissão das colunas
  Melhorias na API dos Datablades
• Rotinas SPL para compatibilidade aplicacional
  Mais uma surpresa. Esta funcionalidade não será novidade para quem esteja a participar no processo de avaliação da próxima versão (EVP), mas é surpreendente vê-la na 11.7. A ideia por detrás disto é extremamente simples, e devo confessar que sou um fã da mesma. Todos sabemos que o Informix é facilmente extensível e que é fácil criar funções em C que implementem funções que não existem no Informix. Inclusivamente já tenho publicado alguns artigos dando alguns exemplos. Assim, é com grande prazer que vejo a IBM decidir implementar funções "de compatibilidade" num novo datablade. Mais especificamente alguns pacotes bem conhecidos, chamados DBMS_ALERT, DBMS_LOB, DBMS_OUTPUT, DBMS_RANDOM, UTL_FILE foram implementados.
  Isto pode ser uma enorme ajuda a quem esteja a portar aplicações para Informix
  
• Dados Time Serie
• Carregar dados time series mais rápido através de uma tabela virtual
  Melhoria de performance na interface de tabela virtual sobre repositórios TimeSeries

Alguns comentários finais:

1. Durante uma troca de emails com um dos arquitetos do Informix, há alguns anos atrás, ele escreveu algo como "devemos evitar criar muitos parâmetros... Tentemos manter a coisa simples"
   Não posso estar mais de acordo com ele, e ver tantos novos parâmetros assusta-me um pouco e relembra-me esta conversa. Por outro lado um parâmetro significa controlo e eu gosto disso. Diria que são um mal necessário. A parte boa é que estão normalmente bem comentados no ONCONFIG de exemplo e que os novos que têm sido introduzidos são normalmente dinâmicos
2. Se trabalhasse no marketing, por esta altura estaria provavelmente a esconder funcionalidades para que as pudesse anunciar aquando da próxima versão. É bom ver que tal não está a acontecer, e que a preocupação continua a ser entregar funcionalidades aos clientes logo que possível
3. Por favor, por favor, por favor!.... Que a introdução dos packages de compatibilidade seja apenas o princípio. Não consigo encontrar nenhuma razão para que funções não sejam implementadas desta forma, mesmo que isto não seja a implementação mais rápida. Na maioria dos casos os programadores necessitam da funcionalidade mais que da performance. E mais tarde podem ser movidas para a implementação na camada de SQL nativa sem quebrar a compatibilidade. Isto não poderá ser a solução para alguma sintaxe do SQL, mas para funções "puras" eu escolheria este caminho. E na realidade não é novo. Já vimos isto em bladelets disponíveis para o público