#SQL

¡Hola desarrolladores!

A veces necesitamos insertar o referir los datos de clases directamente en globals.

Y quizá muchos de vosotros esperáis que la estructura de datos de una global con registros sea:

^Sample.Person(Id)=$listbuild("",col1,col2,...,coln).

Este artículo es un aviso de que esto no siempre es verdad, así que no se debe dar por supuesto!

En SQL, la condición más frecuente WHERE se relaciona principalmente con el contenido de las filas en las que trabajas.
Por lo tanto, debe calcularse y verificarse para cada fila a la que accedas.
Distinto es el caso (y por eso la llamé ESTÁTICA) de una condición WHERE independiente de las filas a las que accedes.

Encontrar errores en tu código o examinar un comportamiento inesperado es el principal objetivo de la depuración.

Trataré de actualizar las herramientas tradicionales aparte de las ayudas que tienen Studio, VScode, Serenji... Las herramientas básicas que han estado ahí antes de que tu EDI preferido lo utilizara en segundo plano.

Una de nuestras apps utiliza una consulta de clase para un informe ZEN y funciona perfectamente en ese informe, produciendo los resultados esperados. Hemos migrado a InterSystems Reports y nos hemos dado cuenta de que, para un informe que utiliza la misma consulta de clase, aparecen en la parte de abajo más de 100 filas extra con los mismos valores en las columnas.

Descartamos InterSystems Reports como fuente del problema reproduciendo el problema de "filas extra" con una hoja de cálculo de Excel que llama a la misma consulta de clase utilizando un procedimiento almacenado.

¿Cuál era el problema? Cuando llamábamos al procedimiento almacenado desde el antiguo ZEN Report o desde la función SQL Query en el Portal de Administración, no veíamos estas filas adicionales.

Una de las razones por las que me encantan Cache e IRIS es que no solo puedes hacer cualquier cosa que puedas imaginar, sino que también puedes hacerlas de un montón de maneras diferentes!!

Imagina que tienes una integración con IRIS (o Cache) funcionando conectada por ODBC. Probablemente solo uses consultas SQL, pero puedes usar también procedimientos almacenados y dentro de su código puedes hacer cualquier cosa que puedas imaginar.

Voy a darte algunos ejemplos, pero el límite está en tu imaginación!

Quizás te estés diciendo... ¡espera!! Yo no sé como crear un procedimiento almacenado en IRIS... Pero eso no es cierto, sabes crearlo! Lo que pasa que todavía no lo sabes...

El orden es una necesidad para todos, pero no todos lo entienden de la misma manera (Fausto Cercignani)

Nota de traducción: este articulo se publicó originalmente basado en Caché. Para esta traducción se revisó todo el contenido usando InterSystems IRIS.

Descargo de responsabilidad: En este artículo se utilizan el ruso y el alfabeto cirílico como ejemplos, pero esto solamente es importante para las personas que utilizan InterSystems IRIS en lugares en los que no se habla inglés. Ten en cuenta que este artículo se refiere principalmente a las compilaciones de NLS, que son diferentes a las compilaciones de SQL. Las compilaciones en SQL (por ejemplo, SQLUPPER, SQLSTRING, EXACT que significa que no hay compilación, TRUNCATE, etc.) son funciones reales que se aplican de manera explícita a algunos valores, y cuyos resultados a veces se almacenan explícitamente en los subíndices de los *globals. De hecho, cuando se almacenan en subíndices, de forma natural estos valores seguirían la compilación de NLS (“Compilaciones de SQL y NLS”).*

¡Hola Desarroladores!

IRIS External Table es un proyecto de código abierto de la comunidad de InterSystems, que permite utilizar archivos almacenados en el sistema de archivos local y almacenar objetos en la nube como AWS S3 y tablas SQL.

¡Hola desarrolladores!

Como probablemente sabéis, en IRIS 2021 los nombres de los globals son aleatorios.

Y si creas clases de IRIS con DDL y quieres estar seguro de qué global se creó, seguramente te gustaría darle un nombre.

De hecho, se puede hacer.

Usa WITH %CLASSPARAMETER DEFAULTGLOBAL='^GLobalName' en la Tabla CREATE para que funcione. Documentación. Mirad este ejemplo:

¡Hola amigos!

A veces necesitamos importar datos a InterSystems IRIS desde archivos de tipo CSV. Esto puede hacerse, por ejemplo, mediante la herramienta csvgen, que genera una clase e importa todos los datos a ella.

Pero, ¿qué pasa si tienes tu propia clase y quieres importar datos desde un archivo CSV a una tabla que ya existe previamente?

Hay varias formas de hacerlo, ¡pero puedes utilizar csvgen (o csvgen-ui) otra vez! Preparé un ejemplo y estoy encantado de compartirlo con todos. ¡Vamos allá!

Digamos que tengo una clase persistente en IRIS con una propiedad opcional EmailOptIn:

Class Person Extends %Persistent
{
Property Name As %String;
Property EmailOptIn As %Boolean;
}

Más tarde me doy cuenta de que estoy haciendo muchas comprobaciones nulas en esta propiedad donde no debería ser necesario. La solución es hacer de esto una propiedad requerida:

Hay una nueva funcionalidad muy interesante en la recientemente anunciada versión de prueba 2024.1 de InterSystems IRIS - JSON_TABLE. JSON_TABLE forma parte de una familia de funciones introducidas en la versión 2016 del estándar SQL (ISO Standard, publicado a principios de 2017). Permite que valores JSON se mapeen a columnas y se consulten usando SQL. JSON_TABLE puede usarse en la cláusula FROM de algunas sentencias SQL.

La sintaxis de JSON_TABLE es bastante extensa, permitiendo condiciones excepcionales cuando los valores JSON proporcionados no cumplen las expectativas, estructuras anidadas, etc.

La sintaxis básica es bastante sencilla. El primer argumento pasado a JSON_TABLE es el valor JSON que se va a consultar. Puede ser un literal, una referencia a una columna o una llamada a una función. El segundo argumento es una expresión JPL (JSON Path Language), que permite filtrar el valor proporcionado. Después va la cláusula COLUMNS - justo en medio de la llamada a la función. La cláusula COLUMNS se parece mucho a las definiciones de columnas en una sentencia CREATE TABLE pero con un añadido muy necesario - el PATH. PATH es una expresión JPL que se aplica al valor JSON para producir el valor de la columna.

En este tutorial, me gustaría hablar sobre las Consultas de Clase (Class Queries). Para ser más precisos, sobre las Consultas basadas en código escrito por el usuario:

Recientemente surgió un patrón interesante en torno a los índices únicos (en una discusión interna re: isc.rest) y me gustaría destacarlo para la Comunidad.

Como caso de uso motivador: supón que tienes una clase que representa un árbol, donde cada nodo también tiene un nombre, y queremos que los nodos sean únicos por nombre y nodo principal. Queremos que cada nodo raíz también tenga un nombre único. Una implementación natural sería:

En este artículo demostraré lo siguiente:

• Cómo actualizar ReferencesRange (OBX: 7) contra ObservationIdentifier (OBX: 3.1) [TestCode] de la base de datos mediante la función de utilidad personalizada
• Cómo actualizar Abnormal Flag (OBX: 8) contra ObservationIdentifier (OBX: 3.1) [TestCode] y ObservationValue (OBX: 5) [Resultado] desde la función de utilidad de base de datos
• Mensaje de ruta basado en un Abnormal Flag (OBX: 8)