Artículo
Joel Espinoza · Oct 28, 2019 Lectura de 4 min
Cómo reenviar solicitudes en un servicio REST

¡Hola Comunidad!

Una función útil de nuestra estructura REST es la capacidad que tienen las clases de Dispatch para identificar los prefijos de una solicitud y redireccionarlos a otra clase de Dispatch. Este enfoque permite mejorar el orden y la lectura del código, permite mantener separadas las versiones de una interfaz fácilmente y ofrece una forma de proteger llamadas a APIs a las que solo ciertos usuarios podrán acceder.

00
0 1 93

11 de febrero, 2021 – Aviso: Resultados de búsqueda incompletos con ‘ORDER BY <row ID field> DESC’ – HealthShare

InterSystems ha corregido un fallo que puede producir resultados de búsqueda incompletos. Este fallo afecta a las plataformas que son la base de HealthShare y HealthShare Health Connect:

00
0 0 12

¡Hola desarrolladores!

Es un placer anunciar la disponibilidad del Registro de Contenedores de InterSystems. Es un nuevo canal para que los clientes tengan acceso a las versiones finales y de prueba de software, en formato apto para contenedores. Todas las imágenes Community Edition están disponibles en un repositorio público que no necesita autenticación. Las imágenes finales (IRIS, IRIS for Health, Health Connect, System Alerting and Monitoring, InterSystems Cloud Manager) y las utilidades (como pueden ser arbiter, Web Gateway y PasswordHash) requieren un token de autenticación que se genera a partir de las credenciales de la cuenta del WRC.

00
0 0 43

InterSystems ha corregido dos defectos que afectan al backup online de grandes bases de datos. Los backups realizados a través de métodos externos, como snapshots o copias directas de ficheros, no están afectados. Estos defectos existen en todas las versiones de los productos de InterSystems.

00
0 1 50
InterSystems Official
David Reche · Mar 24, 2020
Varios avisos sobre HealthShare (23 de marzo)

Este mensaje contiene tres Avisos recientes sobre HealthShare.

El detalle de estos avisos también se encuentran en la página de Alertas y Avisos de Productos de InterSystems

  • Advisory: Patient data is missing in the HSAA.PatientNumber table
  • Advisory: The UpdatePlan for all cubes and cube groups is set to be Manual instead of BuildSynch
  • Advisory: Slow DELETE query during Health Insight data ingestion

Si tenéis alguna pregunta sobre estos avisos, contactad por favor con el Centro de Soporte Internacional (WRC).

00
0 0 44

Esta publicación es el resultado directo de trabajar con un cliente de InterSystems que acudió a mí con el siguiente problema:

SELECT COUNT(*) FROM MyCustomTable

Esto tarda 0.005 segundos, con 2300 filas en total.  Sin embargo:

00
0 0 62

Actualización 30/01/2020

*** Las versiones afectadas de los productos han cambiado ***

*** Las versiones afectadas son Caché y Ensemble desde 2016.2.0.  ***

*** Caché y Ensemble 2016.1.0 no está afectada por este defecto ***

InterSystems ha corregido un defecto que puede ocasionar degradación de la base de datos en circunstancias muy excepcionales. Puede incluir (y no limitarse a) problemas relacionados, como datos de la aplicación incorrectos o desaparecidos y sistemas bloqueados.

Este defecto afecta a:

00
0 0 47

InterSystems ha corregido un defecto que puede ocasionar que el servicio de shadowing falle con una violación de acceso. En algunos casos, el defecto puede causar corrupción de memoria, produciendo un comportamiento impredecible. 

Nota: El defecto no afecta al mirroring.

El defecto afecta a:

00
0 0 51

InterSystems ha corregido varios defectos críticos que pueden ocasionar problemas de integridad de datos. Estos defectos han sido identificados y corregidos en un breve espacio de tiempo, por lo que InterSystems ha simplificado el proceso de actualización consolidándolos en un único paquete. Los efectos de estos fallos puede que no sean siempre visibles. Los defectos afectan a los productos InterSystems IRIS, IRIS for Health, Health Connect, Caché, Ensemble y HealthShare. Todos los defectos están relacionados con la aplicación de datos de journals.

00
0 0 50

¡Hola a tod@s!

¿Le parece que son demasiado lentas las consultas sobre el rango de las fechas?  ¿Le parece que el rendimiento de SQL es bajo?  ¡Tengo un truco curioso que podría ayudarle a solucionar estos problemas! (¡Los desarrolladores de SQL detestan que conozca estas cosas!)*

Si tiene una clase que almacena el historial de registro de la hora cuando se agregan datos, entonces esos datos se ordenarán con sus valores IDKEY, es decir, TimeStamp1 < TimeStamp2  si y solo si la condición ID1 < ID2 se cumple para todos los valores ID y TimeStamp en la tabla, entonces puede utilizar esta información para aumentar el rendimiento de las consultas en relación con los rangos de TimeStamp.  Examine la siguiente tabla:

10
0 0 201