Aha! It's worth it / Aha! Vale a pena!

The joys of Aha (original version here)

English version

In my most recent article I mentioned several features that will be implemented in the future major release of Informix and wrote that several of them came from "customer" requests and a couple of them I had inserted myself in the current or old Request For Enhancements page (now called Aha).
It just happens that today I had to open a new request for another IBM product, and the site listed my requests... And some of them are quite interesting:

• Allow remote query execution inside a TRUSTED CONTEXT (opened in 2019)
  Mentioned in the article and refused. For me this will still prevent the use of SET SESSION AUTHORIZATION...
• MSG_DATE format should follow $DBDATE if defined (opened in 2016)
  Refused although the parameter was changed in 14.10.FC4 to allow for another (fixed) format.
  The code was changed to a less flexible option...
• Allow PAM in OleDB clients (for password mode) (opened in 2016)
  Refused. This means client applications with OleDB can't use PAM ports. The situation is even more complex because any client which doesn't send the CLIENT_PAM_CAPABLE will be prevented to connect to a PAM enabled port when that is irrelevant for user/password authentication when using PAM. This includes 3rd party drivers for example.
  
• SQL interface to obtain the temporary space usage (tables, hash, sorts...) (opened in 2015)
  Implemented!
• Add SID to audit log (opened in 2015)
  Mentioned in the article and one to be implemented in vNext!
• Require NODEFDAC as a server side general setup (opened in 2014)
  Refused. We still have the server grant all privileges in non-ANSI databases by default. It would be a nice thing to be added since there are plans to implement certain ANSI features in non-ANSI databases!
• Allow DBA to re-initialize OS process cache created by the resolver routines (opened in 2014)
  Refused. This means that if a change is made in the DNS infra-structure we need to restart the database engine. The issue is documented in this blog article which includes an hack documented in this blog that may workaround this but I doubt any customer would want to do that (I already did it in a customer...). There's another workaround documented here which is a bit more elegant.
  
• Improve performance of L1/L2 backups (opened in 2014)
  Marked as "Future consideration". I mentioned this in the vNext article, because the increase in timestamp range will allow the use of L1/L2 in high activity servers, but they'll still be painfully and unnecessarily slow
  
• Allow column ALIAS in HAVING clause (opened in 2014)
  Refused. Less compatibility with other RDBMs SQL and more complicated SQLs
  
• Allow "group commit" as other RDBMS (opened in 2014)
  Marked as "Future consideration". A possible performance optimization.
  
• Obtain the query plan of a running query (opened in 2013)
  Mentioned in the article and one to be implemented in vNext!
• Upgrade of secondary server without restore from primary (opened in 2013)
  Refused, although we can do it with a lot of limitations which I think we wouldn't have with the solution I proposed

I just mentioned the features I requested in Aha (there are a few more I suggested in the previous site). Many of them were refused. Some were or will be implemented. And some are still marked for "future consideration" which means they may still be implemented. It may seem that the majority is ignored/refused, so why do I think it's worth it? Because it may take around 5m to open it... it's easy! And it's somehow rewarding when you see that development actually implemented something you requested.

 

 

Versão Portuguesa

No meu artigo mais recente mencionei algumas funcionalidades que serão implementadas na próxima versão do Informix e indiquei que algumas delas derivam de pedidos de "clientes" e um par delas teriam sido inseridas por mim no actual ou antigo site de pedidos de melhorias (agora chamado  Aha).
Por coincidência, hoje estive a abrir mais um pedido para outro produto IBM, e no site reparei na lista dos meus pedidos... alguns são bastante interessantes:

• Allow remote query execution inside a TRUSTED CONTEXT (aberto em 2019)
  Mencionado no artigo e recusado. Para mim isto irá impedir muitas utilizações da instrução SET SESSION AUTHORIZATION...
• MSG_DATE format should follow $DBDATE if defined (aberto em 2016)
  Recusado ainda que o parâmetro tenha sido alterado na versão 14.10.FC4 para permitir outro formato (fixo).
  
• Allow PAM in OleDB clients (for password mode) (aberto em 2016)
  Recusado. Isto implica que aplicações clientes que usem OleDB não podem usar portos configurados com PAM. Esta situação é ainda mais complexa, pois qualquer cliente que não envie a "variável" CLIENT_PAM_CAPABLE será impedido de conectar-se a um port configurado com PAM, quando tal é irrelevante para autenticações com utilizador/senha, mesmo que tenham outros módulos PAM. Isto incluí drivers de terceiros por exemplo. 
• SQL interface to obtain the temporary space usage (tables, hash, sorts...) (aberto em 2015)
  Implementado!
• Add SID to audit log (aberto em 2015)
  Mencionado no artigo e para ser implementado na vNext!
• Require NODEFDAC as a server side general setup (aberto em 2014)
  Recusado. Ainda temos o servidor a dar todos os privilégis em bases de dados não-ANSI. Seria uma boa adição, já que há planos de implementar certas características de bases de dados ANSI em bases de dados não-ANSI!
• Allow DBA to re-initialize OS process cache created by the resolver routines (aberto em 2014)
  Recusado. Isto implica que se fizermos uma mudança na infra-estrutura de DNS teremos de re-iniciar o Informix. O problema está descrito neste artigo e incluí um truque que pode ser utilizado como workaround mas duvido que os clientes o queiram usar (eu já o usei num cliente). Num outro artigo descrevo uma forma mais elegante de contornar o problema.
  
• Improve performance of L1/L2 backups (aberto em 2014)
  Marcado como "Future consideration". Eu mencionei isto no artigo sobre a vNex,  porque o aumento do tamanho do timestamp vai permitir usar os arquivos L1/L2 em ambientes com muita actividade, mas estes continuarão a ser desnecessariamente lentos.
  
• Allow column ALIAS in HAVING clause (aberto em 2014)
  Recusado. Implica menor compatibilidade com SQL de outros RDBMS e SQLs mais complicados.
  
• Allow "group commit" as other RDBMS (aberto em 2014)
  Marcado como "Future consideration". Uma possível melhoria de performance.
  
• Obtain the query plan of a running query (aberto em 2013)
  Mencionado no artigo e um a ser implementado na vNext!
• Upgrade of secondary server without restore from primary (aberto em 2013)
  Recusado, embora se possa fazer com uma série de limitações, que eu penso que não existiriam com a solução que propus.

Apenas mencionei os pedidos que fiz no Aha (haveria outras que sugeri no site antigo). Muitos foram recusados. Alguns foram ou serão implementados. E alguns estão marcados como "Future consideration" o que significa que poderão ainda ser implementados. Pode parecer que a maioria é ignorado/recusado, portanto porque acredito que vale a pena? Porque pode demorar cerca de 5m a abrir um pedido. É fácil! E é de alguma forma gratificante quando vemos que o desenvolvimento efectivamente implementou algo que sugerimos.