Pesquisar

Pergunta
· Jun. 3

What's this odd behavior with "select count()" and a Unique Index?

Hello,

I have a class with a "Unique" index (pxfactidIndex) on a %Numeric property (pxfactid) (partially-edit code snippet below):

Property pxfactid As %Library.Numeric(MAXVAL = 9223372036854775807, MINVAL = -9223372036854775808, SCALE = 0) [ SqlColumnNumber = 7 ];
Index pxfactidIndex On pxfactid [ Unique ];
Storage Default
{
<Data name="FactDefaultData">
<Value name="1">
<Value>pysubjectid</Value>
</Value>
...
<Value name="6">
<Value>pxfactid</Value>
</Value>
...
</Data>
<DataLocation>^CRMBI.FactD</DataLocation>
<DefaultData>FactDefaultData</DefaultData>
<ExtentLocation>^CRMBI.Fact</ExtentLocation>
<ExtentSize>3521840</ExtentSize>
<IdFunction>sequence</IdFunction>
<IdLocation>^CRMBI.FactD</IdLocation>
<Index name="DDLBEIndex">
<Location>^CRMBI.FactI.2</Location>
</Index>
<Index name="IDKEY">
<Location>^CRMBI.FactD</Location>
</Index>
<Index name="pxfactidIndex">
<Location>^CRMBI.Fact.4</Location>
</Index>
...
<IndexLocation>^CRMBI.FactI</IndexLocation>
<Property name="%%ID">
<AverageFieldSize>4.99</AverageFieldSize>
<Histogram>$lb(.06666666666666666667,1,0,$lb(27673,228574,456707,618301,892202,1107091,1405679,1604163,1738513,2015749,2270724,2530345,2830827,3047237,3296375,3504324),$lb(1,0,0,0,0,1,1,1,0,1,1,1,0,1,1),$lb(842479159,926299955,842544439,842151989,875902519,875902519,909195315,909195315,943272498,943272498,825307191,825243440,875574582,875574582,909128753,909128753,926103605,825701176,842019125,808531255,842477623,842477623,892547123,892547123,942878776,842543920,858797111,808728370,842610227,842610227,892351539,859123764))</Histogram>
<Selectivity>1</Selectivity>
</Property>
<Property name="pxfactid">
<AverageFieldSize>9.99</AverageFieldSize>
<Histogram>$lb(.06666666666666666667,1,0,$lb(-8377896048695389137,-7487164305435710908,-6406061662044370629,-5112561079609519767,-4588722295094185245,-4512887624516713113,-3293381287254976544,-1753938466698510428,-1561375857877981192,-211989232600898713,2857966673366783778,4457490938253726327,5246678144060189771,6591622321393794159,8944949574919674333,8944949574921469469),$lb(1,1,1,1,3,1,1,2,1,0,0,0,0,0,11),$lb(758657847,942880567,926169143,926169143,909389878,909389878,892416306,892416306,875903032,943208242,825374776,875901234,858929459,858929459,825701683,926233401,892743987,825570865,842084665,758264113,842544439,842544439,875836727,875836727,892482614,892482614,909457713,909457713,943273012,825833015,842085430,943273012))</Histogram>
<Selectivity>0.0000283942484610317%</Selectivity>
</Property>

I see the following odd behavior when counting how many records have that property set to null:

  • The first query (17) returns the number of records in the table. The 2nd query (18) returns what I expect: all records have non-null values for that "pxfactid" property. However, when I run the 3rd query (19) which counts all records with non-null values in that field, I get a much smaller, unexpected, number.

  • The 4th query (20) counts the number of records in a subquery that returns all non-null values for that property in the table and returns the expected number that matches the total number of records in the table.

Does anyone have any idea of what type of coding error would produce the odd behavior seen in query 19 (wrong number of records with non-null values in that indexed property)?

Note that the values in that field have a large range; here's a sample of some of them:

Thanks

8 Comments
Discussão (8)4
Entre ou crie uma conta para continuar
Anúncio
· Jun. 3

Online Meetup with the Winners of the InterSystems FHIR and Digital Health Interoperability Contest 2025

Hi Community,

Let's meet at the online meetup with the winners of the InterSystems FHIR and Digital Health Interoperability Contest! It's a great opportunity to chat with the InterSystems Experts team and our contestants.

Winners' demo included!

Date & Time: Thursday, June 5, 11:30 am EDT | 5:30 pm CEST

Join us to learn more about winners' applications and to have a talk with our experts.

➡️ REGISTER TODAY

See you all at our virtual meetup! 

1 Comment
Discussão (1)1
Entre ou crie uma conta para continuar
Artigo
· Jun. 3 3min de leitura

¿Cómo gestionar la configuración de InterSystems API Manager en una canalización CI/CD?

Kong ofrece una herramienta de gestión de configuración de código abierto (escrita en Go), llamada decK, que significa declarative Kong en inglés.

  • Comprobar que deck reconoce vuestra instalación de Kong Gateway mediante deck gateway ping
deck gateway ping   
Successfully connected to Kong!
Kong version:  3.4.3.11

  • Exportar la configuración de Kong Gateway a un archivo llamado "kong.yaml" mediante el comando deck gateway dump
deck gateway dump -o kong.yaml

  • Después de modificar direcciones IP en el archivo kong.yaml, se muestran las diferencias mediante deck gateway diff
deck gateway diff kong.yaml

updating service test-iris  {
   "connect_timeout": 60000,
   "enabled": true,
-  "host": "192.168.65.1",
+  "host": "172.24.156.176",
   "id": "8fc9849d-9e61-402d-bcad-c3e611808892",
   "name": "test-iris",
   "port": 9092,
   "protocol": "http",
   "read_timeout": 60000,
   "retries": 5,
   "write_timeout": 60000
 } updating service uct  {
   "connect_timeout": 60000,
   "enabled": true,
-  "host": "192.168.65.1",
+  "host": "172.24.156.176",
   "id": "96ad587e-8921-4d6c-acb7-3f7f7a7cc072",
   "name": "uct",
   "path": "/api/uct/",
   "port": 9092,
   "protocol": "http",
   "read_timeout": 60000,
   "retries": 5,
   "write_timeout": 60000
 } Summary:
  Created: 0
  Updated: 2
  Deleted: 0
deck gateway sync kong.yaml

updating service uct  {
   "connect_timeout": 60000,
   "enabled": true,
-  "host": "192.168.65.1",
+  "host": "172.24.156.176",
   "id": "96ad587e-8921-4d6c-acb7-3f7f7a7cc072",
   "name": "uct",
   "path": "/api/uct/",
   "port": 9092,
   "protocol": "http",
   "read_timeout": 60000,
   "retries": 5,
   "write_timeout": 60000
 } updating service test-iris  {
   "connect_timeout": 60000,
   "enabled": true,
-  "host": "192.168.65.1",
+  "host": "172.24.156.176",
   "id": "8fc9849d-9e61-402d-bcad-c3e611808892",
   "name": "test-iris",
   "port": 9092,
   "protocol": "http",
   "read_timeout": 60000,
   "retries": 5,
   "write_timeout": 60000
 } Summary:
  Created: 0
  Updated: 2
  Deleted: 0
deck gateway dump --workspace workspace1
deck gateway sync workspace1.yaml --workspace workspace1

Para más información:

https://docs.konghq.com/deck/get-started

https://docs.konghq.com/deck/reference/faq/

https://github.com/Kong/deck/blob/main/CHANGELOG.md/

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

Version IKO 3.8

InterSystems Kubernetes Operator (IKO) 3.8 est désormais disponible. IKO 3.8 ajoute de nouvelles fonctionnalités ainsi que de nombreuses corrections de bugs et mises à jour de sécurité. Parmi les points forts :

  • Les groupes de calcul vous permettent de déployer plusieurs types de nœuds de calcul pour gérer différents types de charges de travail dans un seul cluster Iris.
  • Consolidation des volumes : vous pouvez désormais choisir de déployer avec moins de volumes, par exemple pour consolider les données et WIJ sur un même volume.

Suivez le Guide d'installation pour savoir comment télécharger, installer et démarrer avec IKO. La documentation complète d'IKO 3.8 vous fournit plus d'informations sur IKO et son utilisation avec InterSystems IRIS et InterSystems IRIS for Health. IKO peut être téléchargé depuis la page de téléchargement de WRC (recherchez Kubernetes). Le conteneur est disponible dans le registre de conteneurs InterSystems.

IKO simplifie l'utilisation d'InterSystems IRIS ou d'InterSystems IRIS for Health dans Kubernetes en fournissant une définition de ressource irisCluster facile à utiliser. Consultez la documentation pour obtenir la liste complète des fonctionnalités, notamment le partitionnement, la mise en miroir et la configuration d'ECP.

Discussão (0)0
Entre ou crie uma conta para continuar
Anúncio
· Jun. 3

Ganadores del Concurso de Interoperabilidad en Salud Digital y FHIR de InterSystems 2025.

Hola comunidad:

¡Es hora de anunciar a los ganadores del Concurso de Interoperabilidad en Salud Digital y FHIR de InterSystems!

Gracias a todos los increíbles participantes, que enviaron 11 aplicaciones 🔥

¡Es hora de anunciar a los ganadores!

Nominación de los expertos

🥇 1.er lugar y $5,000 para la aplicación FHIRInsight de @José Pereira, @Henry Pereira, @Henrique Dias

🥈 2.º lugar y $2,500 para la aplicación iris-fhir-bridge de @Muhammad Waseem

🥉 3.er lugar y $1,000 para la aplicación health-gforms de @Yuri Marx

🏅 4.º lugar y $500 para la aplicación fhir-craft de @Laura Blázquez García

🏅 5.º lugar y $300 para la aplicación CCD Data Profiler de @Landon Minor

🌟 $100 para la aplicación IRIS Interop DevTools de @Chi Nguyen-Rettig

🌟 $100 para la aplicación hc-export-editor de @Eric Fortenberry

🌟 $100 para la aplicación iris-medbot-guide de @shan yue

🌟 $100 para la aplicación Langchain4jFhir de @Erick Hideki Murakami

🌟 $100 para la aplicación ollama-ai-iris de @Oliver Wilms

Nominación de la comunidad

🥇 1.er lugar y $1,000 para la aplicación iris-medbot-guide de @shan yue

🥈 2.º lugar y $600 para la aplicación FHIRInsight de @José Pereira, @Henry Pereira, @Henrique Dias

🥉 3.er lugar y $300 para la aplicación FhirReportGeneration de @XINING MA

🏅 4.º lugar y $200 para la aplicación iris-fhir-bridge de @Muhammad Waseem

🏅 5.º lugar y $100 para la aplicación fhir-craft de @Laura Blázquez García

¡Nuestras más sinceras felicitaciones a todos los ganadores!

¡Únete a la diversión la próxima vez! 😉

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