検索

Artigo
· Mar. 7 2min de leitura

SQL Query Stopped Working After Changing %String Property to Wrapper Types

We recently changed the 'UserID" property in a "User" class from type of %String to be %Library.Username. This is for better consistency across our codebase regarding MAXLEN limit.

%Library.Username is a system wrapper datatype which extends %String and has a MAXLEN of 160. This change should have minimal/no impact on code behavior. However, we found that some SQL query cannot return expected rows after the change. Query will return empty values even if the entry is in the table.

After investigation, we found that re-building index could solve the issue, which means the data type change caused some inconsistency for existing index on the property. But why would a simple wrapper class of String make any difference in SQL table?

 

==================================================================================

Answer:

The reason index stopped working is that it was built when the property was still a %String.

So what's the difference between %Library.String and %Library.Username? They are both %String. But aside from MAXLEN, another key difference is the default COLLATION.

In SQL, by default, an index on a given property (or properties) uses the collation type of the property data. For %Library.String, there is a system-wide (namespace-wide) default COLLATION="SQLUPPER" (this default can be changed, see the documentation below). This means that if we have a row with UserID="JoeFu", it’s stored in the UserIDIndex global as " JOEFU".

For WHERE clause comparison: UserID="JoeFu", with default collation of UserID="SQLUPPER", the SQL engine evaluates it as %SQLUPPER(UserID)=%SQLUPPER("JoeFu").

However, when we switch to %Library.Username, there is no default COLLATION anymore (sadly, even if this type is pretty much just %String). Now, without "SQLUPPER" collation, SQL engine evaluates this equal condition as it is: UserID="JoeFu", then query optimizer decides to use the index built upon UserID, without rebuilding this index, we still have %SQLUPPER(UserID) in this index global. When it looks for "JoeFu" without such collation, it cannot find a match.

NOTE: when creating/using datatype that replacing %String, should pay attention to the usage of the property and its index, it's very possible that you need to set COLLATION="SQLUPPER" to match things in the existing SQL table

See https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=RSQL_stringmanipulation#RSQL_stringmanipulation_desc for SQL string collation.

See https://docs.intersystems.com/iris20243/csp/docbook/DocBook.UI.Page.cls?KEY=GSQL_collation#GSQL_collation_ns for the setting of default collation on IRIS

See https://docs.intersystems.com/iris20243/csp/docbook/DocBook.UI.Page.cls?KEY=GSQL_collation#GSQL_collation_indexdef for Index collation.

Thanks Yuchen Liu for answering my initial question!

3 Comments
Discussão (3)1
Entre ou crie uma conta para continuar
Pergunta
· Mar. 7

Dynamic SQL Queries with a ROUTINE (CODE) database mounted in read-only mode: ERROR #5002: ObjectScript error: <UNDEFINED>ShowPlan+6^%apiSQL *sqlOrig

Using IRIS 2024.1.2 when I mount the routine database as read-only I get an error when executing dynamic SQL queries.

What globals need to be mapped in a read-write database in order to allow execution plans to be written?

1 Comment
Discussão (1)1
Entre ou crie uma conta para continuar
Pergunta
· Mar. 7

Requêtes SQL Dynamique avec une base de ROUTINE (CODE) montée en lecture seule : ERROR #5002: ObjectScript error: <UNDEFINED>ShowPlan+6^%apiSQL *sqlOrig

En utilisant IRIS 2024.1.2 lorsque je monte la base de données de routine en lecture seule, j'obtiens une erreur lors de l'exécution de requêtes SQL dynamique.

Quelles globales doivent être mappées dans une base de données en lecture-écriture afin de permettre l'écriture des plans d'exécutions ?

Discussão (0)1
Entre ou crie uma conta para continuar
InterSystems Oficial
· Mar. 7

Descontinuação do MultiValue no InterSystems IRIS 2025.1

A partir da plataforma de dados InterSystems IRIS® versão 2025.1, a InterSystems está oficialmente descontinuando o MultiValue e incluindo-o na lista de Recursos Descontinuados e Obsoletos. Embora a InterSystems continue a oferecer suporte aos clientes existentes que usam o MultiValue, ele não é recomendado para novos aplicativos.

O Que Isso Significa:

  • Suporte Contínuo: O suporte para MultiValue ainda estará disponível por meio do Worldwide Response Center (WRC) em uma base de "melhor esforço", como é fornecido para lançamentos mais antigos do que nossas Versões Mínimas Suportadas.
  • Possibilidade de Remoção Futura: Embora não haja planos imediatos para remover o MultiValue de nossos produtos, a InterSystems reserva-se o direito de fazê-lo em um lançamento futuro.
  • Orientação ao Cliente: Se você tiver dúvidas sobre seu uso atual ou planejado do MultiValue, recomendamos que você entre em contato com sua equipe de conta da InterSystems para obter orientação.

A designação obsoleta sinaliza que os clientes devem planejar eliminar o uso do MultiValue. Reconhecemos que isso pode impactar projetos em andamento e agradecemos sua cooperação à medida que continuamos a evoluir nossa plataforma.

Para mais informações ou preocupações, sinta-se à vontade para comentar abaixo ou entrar em contato com seu representante da InterSystems.

Discussão (0)1
Entre ou crie uma conta para continuar
Artigo
· Mar. 7 7min de leitura

Especificações de Geração de OpenAPI

Introdução

Uma API REST (Representational State Transfer ou Transferência de Estado Representacional) é uma interface que permite que diferentes aplicações se comuniquem entre si através do protocolo HTTP, usando operações padrão como GET, POST, PUT e DELETE. APIs REST são amplamente utilizadas no desenvolvimento de software para expor serviços acessíveis por outras aplicações, possibilitando a integração entre diferentes sistemas.

No entanto, para garantir que as APIs sejam fáceis de entender e usar, uma boa documentação é essencial. É aqui que o OpenAPI entra em cena.

OpenAPI é um padrão para descrever APIs RESTful. Ele permite uma definição estruturada da funcionalidade de uma API, especificando endpoints disponíveis, tipos de dados aceitos e retornados, parâmetros necessários e respostas esperadas. Todas essas informações são coletadas em um arquivo de especificação (geralmente com extensão .yaml ou .json), que pode ser interpretado por ferramentas automatizadas para gerar código, documentação e muito mais.

A Especificação OpenAPI é projetada para ser legível tanto por máquinas quanto por humanos, possibilitando a descrição, produção, consumo e visualização de serviços web RESTful de forma padronizada. Portanto, um documento OpenAPI representa uma descrição formal da API, útil tanto para desenvolvedores que precisam usá-la quanto para ferramentas que podem aproveitá-la para automatizar vários processos.

Por que é útil definir um arquivo de especificação?

Adotar o OpenAPI para documentar uma API oferece diversos benefícios:

  • Clareza: Ele fornece documentação detalhada e estruturada, permitindo que os desenvolvedores entendam rapidamente como interagir com a API, quais requisições enviar e quais dados esperar em resposta.
  • Automação: A documentação pode ser gerada automaticamente a partir do código, mantendo-se atualizada com quaisquer alterações na API.
  • Interatividade: Ferramentas como o Swagger, um conjunto de código aberto para documentação e teste de APIs, incluem o Swagger UI. Isso permite explorar e testar APIs diretamente do navegador, simplificando o desenvolvimento, a verificação e a compreensão das APIs.
  • Padronização: Usar o OpenAPI garante que a documentação siga um formato compartilhado e reconhecido, facilitando a integração com outras ferramentas e serviços.

Como você pode produzir um documento OpenAPI?

Existem duas abordagens principais para gerar um arquivo de especificação OpenAPI:

  • Abordagem "Código-primeiro" (automática): Se uma API REST já foi desenvolvida no InterSystems IRIS, você pode gerar automaticamente a documentação OpenAPI sem escrever manualmente o arquivo de especificação. O IRIS oferece um recurso integrado para exportar a documentação OpenAPI em formato JSON ou YAML, com base nas definições de classe REST.
  • Abordagem "Especificação-primeiro" (manual): Neste caso, o arquivo OpenAPI é escrito manualmente em YAML ou JSON, descrevendo todos os endpoints, parâmetros e respostas esperadas. Essa abordagem é útil quando você deseja definir a API antes de implementá-la, facilitando o design e o compartilhamento com outros desenvolvedores ou stakeholders.

Abordagem Automática

Existem duas maneiras de gerar automaticamente o arquivo de especificação OpenAPI no InterSystems IRIS.

Método 1: Usando a Função GetWebRESTApplication

Uma abordagem é usar a função GetWebRESTApplication fornecida pela classe %REST.API.

Um exemplo prático de como usá-la é adicionando a seguinte função na classe de despacho:

ClassMethod GenerateOpenAPI() As %Status
{
    // The name of the REST application
    Set webApplication = "MyAPP"  // Replace with the name of your web app
    // Retrieve the OpenAPI 2.0 documentation
    Set sc = ##class(%REST.API).GetWebRESTApplication("", webApplication, .swagger)
    
    If $$$ISERR(sc) {
        Quit sc  // If an error occurred, exit the method
    }
    
    // Return the documentation in JSON format
    Set %response.ContentType = "application/json"
    Do ##class(OMRREST.impl).%WriteResponse(swagger.%ToJSON()) 

    Quit $$$OK
}

Adicionalmente, adicione a seguinte rota ao UrlMap:

  <Route Url="/openapi" Method="GET" Call="GenerateOpenAPI"/>

Neste ponto, você terá tudo o que precisa para gerar o arquivo de especificação a partir de sua classe de despacho. Para visualizar a documentação, conecte-se à URL mostrada (onde MyWebapp é o nome da sua aplicação web, conforme definido no portal de gerenciamento):

<host>:<port>/MyWebapp/openapi

O JSON gerado dessa forma representa a especificação OpenAPI da sua API. Após explorar o segundo método, veremos como visualizá-lo e testá-lo no Swagger.

Método 2: Usando a API de Gerenciamento

Outra maneira de gerar o arquivo de especificação OpenAPI é usando a API de Gerenciamento do InterSystems IRIS.

Para chamar este serviço, você pode usar ferramentas como o Postman, que é uma ferramenta de desenvolvedor que permite testar, documentar e automatizar APIs.O Postman fornece uma interface simples e intuitiva para enviar requisições HTTP (GET, POST, PUT, DELETE, etc.), visualizar respostas, gerenciar autenticação e criar testes automatizados.

Para fazer a requisição usando o Postman, siga estes passos:

  1. Clique no botão Novo e crie uma requisição HTTP.
  2. Configure a requisição da seguinte forma e envie-a:
    • Selecione GET como o método HTTP.
    • Especifique a URL no seguinte formato, usando o <baseURL> da sua instância:
      https://<baseURL>/api/mgmnt/v1/namespace/myapp
      Aqui, namespace é o nome do namespace onde você criou o serviço REST, e myapp é o nome da sua aplicação web.
    • Defina o método de Autorização para Basic Auth e forneça o nome de usuário e senha de um usuário com acesso de leitura ao namespace especificado.

Uma vez que o JSON é gerado, ele pode ser visualizado e testado usando ferramentas como o Swagger Editor.

{
   "info":{
      "title":"",
      "description":"",
      "version":"",
      "x-ISC_Namespace":"MyNamespace"
   },
   "basePath":"/MyWebapp",
   "paths":{
      "/loginForm":{
         "post":{
            "parameters":[
               {
                  "name":"payloadBody",
                  "in":"body",
                  "description":"Request body contents",
                  "required":false,
                  "schema":{
                     "type":"string"
                  }
               }
            ],
            "operationId":"loginForm",
            "x-ISC_ServiceMethod":"loginForm",
            "responses":{
               "default":{
                  "description":"(Unexpected Error)"
               },
               "200":{
                  "description":"(Expected Result)"
               }
            }
         }
      },
      "/refresh":{
         "post":{
            "parameters":[
               {
                  "name":"payloadBody",
                  "in":"body",
                  "description":"Request body contents",
                  "required":false,
                  "schema":{
                     "type":"string"
                  }
               }
            ],
            "operationId":"refresh",
            "x-ISC_ServiceMethod":"refresh",
            "responses":{
               "default":{
                  "description":"(Unexpected Error)"
               },
               "200":{
                  "description":"(Expected Result)"
               }
            }
         }
      },
      "/logout":{
         "post":{
            "parameters":[
               {
                  "name":"payloadBody",
                  "in":"body",
                  "description":"Request body contents",
                  "required":false,
                  "schema":{
                     "type":"string"
                  }
               }
            ],
            "operationId":"logout",
            "x-ISC_ServiceMethod":"logout",
            "responses":{
               "default":{
                  "description":"(Unexpected Error)"
               },
               "200":{
                  "description":"(Expected Result)"
               }
            }
         }
      },
      "/openapi":{
         "get":{
            "operationId":"GenerateOpenAPI",
            "x-ISC_ServiceMethod":"GenerateOpenAPI",
            "responses":{
               "default":{
                  "description":"(Unexpected Error)"
               },
               "200":{
                  "description":"(Expected Result)"
               }
            }
         }
      }
   },
   "swagger":"2.0"
}

Abordagem Manual

A abordagem manual para gerar um documento OpenAPI envolve escrever o arquivo de especificação à mão no formato YAML ou JSON. Essa abordagem é particularmente útil quando você deseja controle completo sobre o design da API antes de sua implementação, ou ao documentar uma API já existente sem depender de ferramentas automatizadas

Para escrever o arquivo de especificação OpenAPI, você pode consultar a documentação oficial da versão 2.0 da Especificação OpenAPI, onde encontrará informações sobre campos obrigatórios e como descrever endpoints, parâmetros, respostas e muito mais. Este guia detalhado o ajudará a entender como estruturar adequadamente o arquivo YAML ou JSON para atender aos padrões OpenAPI.

Um bom exemplo de usar essa abordagem é ao criar um serviço REST usando os métodos descritos na documentação oficial do InterSystems IRIS.
Você pode encontrar uma introdução sobre como desenvolver e configurar uma aplicação REST no IRIS seguindo esta página da documentação, que descreve passo a passo os métodos necessários para expor uma aplicação RESTful com IRIS.

Discussão (0)1
Entre ou crie uma conta para continuar