Open ExchangeVariables de host son una característica de programación bastante común en muchas implementaciones de SQL.
Una pregunta reciente en DC me hizo darme cuenta de que en IRIS, Caché, Ensemble,...
las variables del host simplemente existen dentro del embedded SQL.
> You can supply host variables for Embedded SQL queries only. <
Se incluyen ejemplos relacionados en la documentación disponible.
A continuación se incluye una descripción de una solución alternativa si no utiliza o no puede utilizar embedded SQL.
La idea básica es utilizar PPG (Process Private Globals) para almacenar la imitación de una variable del host.
Una de las principales razones para utilizar PPG es el hecho de que se eliminan automáticamente al final del proceso.
Otra idea es evitar conflictos con las matrices de variables locales y el alcance de las variables locales versus globales.
Además, no es necesario realizar ninguna actividad de limpieza.
De hecho, es un conjunto de 3 métodos SQL.
- HDEC para imitar SQL DECLARE @var y SQL SET @-var
- HGETV y HGETI para devolver el valor de la variable como VARCHAR o INTT
- Como característica adicional, se devuelve NULL si la variable no se configuró o declaró antes
- si es necesario devolver cualquier otro tipo de datos es bastante fácil
- HDEL se proporciona si surge la improbable necesidad de eliminar una variable del lenguaje principal
Class User.HostVar
{
ClassMethod GetV(name) As %String [ SqlName = HGETV, SqlProc ]
{
quit $get(^||host($g(name,"%")))
}
ClassMethod GetI(name) As %Integer [ SqlName = HGETI, SqlProc ]
{
quit $get(^||host($g(name,"%")))
}
ClassMethod Declare(name, val) As %Integer [ SqlName = HDEC, SqlProc ]
{
set ^||host($g(name,"%"))=$g(val)
quit $$$OK
}
ClassMethod Del(name) As %Integer [ SqlName = HDEL, SqlProc ]
{
kill ^||host($g(name,"%"))
quit $$$OK
}
}Mi ejemplo contiene 2 variantes para la implementación.
El primero es ObjectScript directo,
esta variante también está disponible en IPM.
El segundo está basado en SQL y se puede implementar también a través de ODBC/JDBC.
CREATE or REPLACE
PROCEDURE HDEC(IN name VARCHAR(50), IN val VARCHAR(50)) RETURNS INT
LANGUAGE OBJECTSCRIPT
{ set ^||host($g(name,"%"))=$g(val)
quit $$$OK
} CREATE or REPLACE PROCEDURE
HGETV(IN name VARCHAR(50)) RETURNS VARCHAR(50)
LANGUAGE OBJECTSCRIPT
{
quit $get(^||host($g(name,"%")))
}CREATE or REPLACE PROCEDURE
HGETI(IN name VARCHAR(50)) RETURNS INT
LANGUAGE OBJECTSCRIPT
{
quit $get(^||host($g(name,"%")))
} CREATE or REPLACE
PROCEDURE HDEL(IN name VARCHAR(50)) RETURNS INT
LANGUAGE OBJECTSCRIPT
{ kill ^||host($g(name,"%"))
quit $$$OK
} Ambas variantes están diseñadas para poder utilizarse sin un prefijo de paquete.
Por lo tanto, se utilizó el paquete Usuario (el predeterminado) que se asigna
al esquema predeterminado SQLUser en SQL.
Durante las pruebas detecté que forzar una secuencia de Configuración y Consumo
Estas variables del host pueden ser un ejercicio complicado si desea ejecutarlas
internamente.una única declaración SQL.
Logré proporcionar una secuencia predecible solo usando una construcción CASE.
SELECT
CASE
WHEN HDEC('rcc',66) > 0 -- set host var
THEN HGETI('rcc')-5||' ** '||HGETV('rcc')
END Dentro de un Stored Procedure no enfrenta este problema.
Se crearon mi ejemplo y también el paquete proporcionado en Open Exchange.
y probado en IRIS. Aunque la construcción es bastante básica y también se
ejecuta sin ningún cambio en Caché, Ensemble, ... y sus derivados y
por supuesto en todos los derivados HEALTH* de IRIS.
Mi única duda es sobre una base de datos sharded en combinación con
Process Private Globals. Simplemente no tenía ninguna configuración disponible para probar este escenario.
No doy por sentado que esta propuesta sea la solución definitiva.
Situaciones específicas pueden requerir un enfoque más sofisticado
o bien construcciones más simples.
Como mencioné anteriormente veo la gran ventaja de tener una solución.
que se puede utilizar a través de un acceso ODBC o JDBC y no
requieren codificación con VSCode o Studio.
Implementation of Ideas Portal
Esperando sus votos en el concurso.