Versão 32

Novidades

Abertura de arquivo no VS Code a partir da IDE do Engine

A IDE do Engine passa a contar com o botão “Open in VS Code”, que abre no VS Code o arquivo que estiver selecionado na IDE.

Open in VS Code

Mais detalhes em https://nginstack.com/pt/docs/vscode/open-from-ide/.

Melhorias

Admin

  • Foi criado o processo Admin > Licenciamento > Utilização do sistema com a finalidade de apresentar uma visão sintética da utilização do sistema. Nele são apresentadas as sessões ativas dos usuários e a relação dos usuários habilitados a utilizar o sistema.
  • O processo Admin > Monitoramento > Sessões de aplicativos passa a permitir filtrar os dados para exibir apenas as sessões de um usuário específico.

Engine

  • As versões mínimas dos bancos de dados suportados pelo Engine passam a ser documentadas em https://nginstack.com/pt/docs/engine/databases/. A leitura dessa documentação é recomendada para todos os desenvolvedores da plataforma, pois ela também trata das transformações realizadas nas expressões SQL a fim de garantir a interoperabilidade entre os SGBDs, assunto que até então não havia sido adequadamente divulgado.
  • O parâmetro datestyle passa a ser configurado automaticamente pelo Engine no acesso ao PostgreSQL, tornando desnecessária a configuração desse parâmetro no arquivo postgres.conf.
  • O Engine passa a suportar os tipos de dados utilizados pelas tabelas de metadados do PostgreSQL, permitindo a consulta direta desses dados sem requerer uma conversão de tipo.
  • O sistema deixa de requerer privilégios de leitura da visão V$SESSION no Oracle, tornando mais simples a configuração desse banco de dados.
  • A classe DataSet passa a permitir a criação de campos do tipo int64.
  • O enumerado DataType foi renomeado para DataSetDataType. Ele passa a enumerar todos tipos de dados suportados pela classe DataSet.
  • Foi criado o enumerado DatabaseDataType com os tipos de dados suportados pelo Engine no acesso às bases de dados.
  • Foi criada a função DataSet.setIntegerDataType com o objetivo de indicar o tipo de dados real dos campos de DataSet quando eles são criados com o tipo 'integer'. Por padrão, o tipo utilizado é 'int32'. Essa função afeta o comportamento global do Engine e seu uso indevido pode provocar a perda de dados.
  • A propriedade Field.prototype.dataType foi renomeada para dsDataType e foi criada a propriedade dbDataType. Essas propriedades indicam os tipos de dados que devem ser utilizados para persistir os valores do campo em um DataSet e na base de dados. Elas são calculadas automaticamente a partir da propriedade type informada na construção do campo e não podem ser alteradas diretamente pelo desenvolvedor.
  • Foi criada a propriedade DateSet.prototype.fieldDefs com o objetivo de manipular as definições de campos de um DataSet. Os métodos dessa classe passam a ser a forma recomendada de criar, alterar e obter as definições de campos. Com a criação desta API, os métodos createField e getFieldType tornaram-se obsoletos por não serem capazes de distinguir os novos tipos de dados 'int32' e 'int64'. Nesses métodos, os dois tipos são identificados como 'integer' a fim de garantir a compatibilidade com os códigos existentes.
  • A conversão de números inteiros do intervalo [Number.MIN_SAFE_INT, Number.MAX_SAFE_INT] em strings passa a utilizar uma representação textual simplificada, sem a indicação de expoente.
  • A configuração de bases de dados no Manage passa a relacionar as opções disponíveis para o campo “Type”. Os campos “Reference” e “MDBC” passam a exibir uma pequena ajuda sobre o seu preenchimento.
  • O construtor da classe File passa a aceitar um parâmetro opcional “encoding”, que indica o tipo de codificação do arquivo que será aberto para leitura ou escrita. Os valores aceitos são “utf-8”, “windows-1252”, “iso-8859-1” ou “binary”. Se não for informado, será considerado o valor padrão “binary”, e o conteúdo do arquivo será tratado como uma string binária, mantendo o comportamento anterior.

Defeitos corrigidos

Admin

  • O processo “Admin > Segurança > Grupos, papéis e usuários > Redefinir senha do administrator” poderia falhar com o erro “Você não tem permissão para alterar a senha de outro usuário” mesmo que o usuário tivesse o escopo de autorização “security.changeUserPassword” configurado.

Desenvolvimento

  • O conteúdo dos arquivos do diretório “/Dados/Arquivos/Atualização/Mensagens de Atualização” com extensão “.txt” estava sendo renderizado como HTML no relatório final do processo Atualizar Sistema. O uso de tags HTML passa a ser permitido apenas em arquivos com extensão “.html”.
  • O processo “Desenvolvimento > Atualização > Atualizar Sistema” poderia gerar diversos erros com a mensagem “Erro ao configurar a constraint NOT NULL da tabela XXXXXX” quando o nome do proprietário do esquema não era igual ao nome da base de dados no Oracle.
  • O processo “Desenvolvimento > Base de dados > Atualizar Estrutura” falhava em identificar as chaves primárias das tabelas quando o nome do proprietário do esquema não era igual ao nome da base de dados no Oracle.
  • O processo “Desenvolvimento > Atualização > Atualizar Sistema” poderia ser interrompido se um registro da tabela “iVfs” tivesse um valor inválido no campo “iParent”.
  • O campo “Destinos recentes” dos processos de atualização deixavam de exibir as bases de dados recentemente atualizadas caso o processo fosse reiniciado por meio de um “Shift + F5” após a seleção da base de dados destino.

Engine

  • O acesso ao “Microsoft SQL Server” falhava caso fosse utilizada a versão 11 do “SQL Server Native Client” ou se fosse informada uma porta diferente da padrão (1433).
  • Colunas do tipo boolean e bit sempre retornavam true em consultas ao PostgreSQL.
  • Ao tentar converter o objeto global em uma string ocorria o erro “Type Error”. Agora passa a ser retornado o valor '[object global]'.
  • Ao iniciar um Engine poderia ser registrado no log o erro “Access Violation” caso a tabela “iApplicationSession” existisse na base de dados, mas não no cache local do servidor.
  • O método virtualFS.setFileContent falhava ao tentar modificar um arquivo de um diretório com erros de definição de classe, impossibilitando a correção desses erros.

Extensão VS Code

  • Na gravação de arquivos de definição de classe (x-class, x-model ou x-view) eram indicados erros de sintaxe se o código-fonte contivesse os comandos deprecated include ou includeOnce. Importante: mesmo com essa correção, o eslint continuará a criticar o uso desses comandos, pois eles não seguem a especificação da linguagem JavaScript. É recomendada a substituição desses comandos deprecated pelas funções equivalentes __include e __includeOnce.
  • As mensagens de erro geradas pelo servidor eventualmente eram exibidas de forma incompleta.

Web Framework

  • Links de relatórios não funcionavam corretamente quando o conteúdo escrito na coluna continha tags HTML.
  • Ao concluir o envio de e-mail de um relatório ocorria o erro “It was not found any field definition to this grid” caso o relatório não tivesse variáveis definidas.
  • O login poderia falhar caso o valor da propriedade httpsConfig da configuração /Configuração/Web Framework/Segurança fosse UseHTTPS.LOGIN.
  • O usuário não tinha a opção de cancelar a exportação de um relatório no diálogo de seleção do tipo de arquivo.

Outras alterações

Admin

  • O relatório Admin > Segurança > Grupos, Papéis e Usuários > Usuários habilitados foi renomeado para Usuários habilitados no período. Ele também passa a não exibir mais os usuários especiais “administrator”, “system” e “anonymous” na relação de usuários habilitados.

Engine

  • Por questões de compatibilidade com versões antigas do Oracle, o operador UNION era tratado como um UNION ALL quando ele era precedido e sucedido exclusivamente por espaços em uma linha. Esse comportamento ocorria apenas no acesso aos bancos de dados Oracle e Microsoft SQL Server, sendo na maioria das vezes indesejado e contornado pelos desenvolvedores por meio de comentários na linha do UNION ou pelo uso explícito do UNION ALL. Esse tratamento foi removido por ser errático e prejudicar a interoperabilidade entre os SGBDs suportados pelo Engine.
  • O Engine deixa de dar suporte às versões de SGBDs descontinuadas pelos seus fornecedores. Os requisitos mínimos passam a ser:
    • PostgreSQL 9.5 ou superior
    • Oracle 11g R2 ou superior
    • Microsoft SQL Server 2017 ou superior
  • A leitura de campos do tipo number de um DataSet como valores inteiros passa a arredondar o valor em vez de truncá-lo. Essa alteração tem o objetivo de tratar melhor a imprecisão da representação numérica de ponto flutuante quando campos com esse tipo armazenam valores inteiros, cenário comum no uso do banco de dados Oracle.
  • Os métodos DataSet.prototype.date e DBKey.prototype.date passam a truncar a componente de hora caso o tipo do campo obtido seja datetime.
  • O driver dblib do Microsoft SQL Server deixa de ser suportado pelo Engine, sendo agora requerido o uso do Native Client.
  • A modificação dos campos “iPassword” e “iStatus” da tabela “iGroupUser” passa a exigir o uso dos métodos da classe Security, como changePassword e setUserStatus. A alteração direta desses campos sem o uso da classe Security provocará a violação da integridade do registro e impedirá o login do usuário até que o administrador redefina a senha do usuário afetado.

REST Framework

  • Erros com status 404 (NOT FOUND) passam a ser logados com a prioridade DEBUG em vez de ERROR, sendo necessário alterar a configuração padrão do log “application” para visualizar esses erros. Esse comportamento foi alterado devido ao erro 404 ser uma sinalização comum em APIs RESTful.

Última atualização em 01 Sep 2020