Tout
Solutions acceptées
Sylvain Guilbaud · Juil 17, 2025 accéder à la publication

Merci @Irène Mykhailova pour ces consignes, toujours utiles.

Je ne sais pas si c'est intentionnel de ta part pour garantir que ton article soit lu correctement par la communauté, mais une faute de frappe s'est glissée : %SYSTEM.JSON n'est pas une classe existante dans IRIS.

Ou s'agit-il simplement d'une hallucination non vérifiée, qui prouverait que tu dois appliquer toi-même tes recommandations pour une utilisation optimale de l'IA générative ?

J'opte pour la première option 😊

Sylvain Guilbaud · Juin 5, 2025 accéder à la publication

L'utilisation de multiples namespaces n'induit pas de surconsommation mémoire directe, mais une mauvaise gestion des mappings ou une configuration sous-optimale des caches peut dégrader les performances. Une planification attentive des accès aux données et des paramètres système adaptés (cache global, $ZSTORAGE, huge pages) permet de maintenir une empreinte mémoire efficace.

1. Mécanisme des namespaces et bases de données

  • Un namespace est une entité logique sans surcoût mémoire intrinsèque.
  • Chaque namespace accède à des bases de données (fichiers IRIS.DAT) via des mappings prédéfinis ou personnalisés.
  • La consommation mémoire dépend principalement :
    • Du cache des globals (mémoire partagée pour les données)
    • Du cache des routines (mémoire partagée pour le code)
    • De la configuration des processus individuels ($ZSTORAGE).

2. Impact des accès multi-bases

  • Accès concurrents à plusieurs bases :
    • Augmente l'utilisation du cache global si les données sont dispersées.
    • Peut entraîner une fragmentation mémoire si les allocations/désallocations sont fréquentes.
  • Mapping intelligent :
    • Des mappings permettent d'optimiser l'accès aux données sans dupliquer les buffers, en partageant des données de référence ou du code entre plusieurs namespaces.

3. Optimisations recommandées

  • Configuration du cache global :
    • Allouer 25-30% de la RAM disponible pour les buffers 8KB (valeur par défaut).
    • Utiliser des huge pages Linux pour réduire la surcharge mémoire.
  • Limite par processus :
    • Ajuster Maximum Per-Process Memory (KB) via le portal (256KB à 2TB).
    • Surveiller les erreurs <STORE> pour détecter les besoins d'ajustement.
  • Stratégie de déploiement :
    • Regrouper les données fréquemment accédées dans une même base ou définir un mapping dans %ALL pour donner un accès à tous les namespaces aux données fréquentes.
    • Utiliser des bases temporaires distinctes pour les opérations transactionnelles lourdes.

4. Comparaison avec les bases en mémoire

InterSystems IRIS évite les écueils des bases purement en mémoire :

Sylvain Guilbaud · Juin 4, 2025 accéder à la publication

@Corentin Blondeau, c'est la nature des 20 flux qui doit être considérée pour décider du nombre de namespaces.


Si les 20 flux sont tous liés entre eux d'un point de vue métier, un seul namespace est recommandé. 
Si parmi ces 20 flux, une vraie séparation métier existe, il est recommandé de les séparer dans plusieurs namespaces, même si certains d'entre eux ne reçoivent qu'un flux, la séparation offrira plus de souplesse dans l'administration et la gestion opérationnelle. 


L'impact sur la consommation mémoire est marginal ; seuls les processus Ens.Actor, Ens.Alarm, Ens.Alert, Ens.MonitorService, Ens.ProductionMonitorService, Ens.ScheduleHandler seront  dupliqués pour chaque nouveau namespace. 

Chaque instance IRIS pouvant supporter jusqu'à 2048 namespaces, il ne faut pas s'en priver dès l'instant où le bénéfice de l'isolation est au rendez-vous 😉

Sylvain Guilbaud · Juin 4, 2025 accéder à la publication

Dans InterSystems IRIS, le choix entre un seul namespace ou plusieurs dépend des besoins en isolation, sécurité, gestion du code et performances.

Si tous les flux sont homogènes d'un point de vue métier, il n'est pas nécessaire de recourir à plusieurs namespaces (plusieurs client utilisent en production des centaines ou des milliers de flux dans un seul namespace).

L'utilisation de plusieurs namespaces offre cependant plusieurs avantages, notamment liés à la sécurité et à l'isolation des processus et données, dès l'instant où vous avez des flux répondant à des besoins métiers hétérogènes ou à des utilisations spécifiques.

Avantages d'utiliser plusieurs namespaces

  1. Isolation des environnements Chaque namespace peut être dédié à un usage spécifique (développement, test, production). Cela réduit les risques de conflits entre configurations.
  2. Sécurité renforcée Les mappings contrôlent précisément l'accès aux données et au code. Un namespace peut restreindre l'accès à certaines bases de données via des règles de mapping global/routine.
  3. Gestion modulaire
    • Configuration indépendante pour chaque flux d'intégration (interopérabilité)
    • Mise à jour/redéploiement partiel sans impacter l'ensemble du système

Inconvénients de multiples namespaces

  1. Complexité accrue de l’administration Plus il y a de namespaces, plus la gestion des mappings, des bases de données associées, des configurations de sécurité, des accès utilisateurs et des stratégies de sauvegarde devient complexe. Chaque namespace nécessite une configuration propre (databases, mappings, sécurité), ce qui multiplie les tâches d’administration et augmente le risque d’erreurs humaines lors des modifications ou migrations.
  2. Gestion des sauvegardes et restaurations La multiplication des namespaces entraîne une augmentation du nombre de fichiers IRIS.DAT à sauvegarder et restaurer. Cela peut rallonger les temps de sauvegarde/restauration et compliquer la gestion des versions et des points de reprise, car il faut garantir la cohérence entre plusieurs bases de données et namespaces.
  3. Verrouillage et contention Les locks sur les globals sont globaux à la base de données : si plusieurs namespaces accèdent à la même base de données via des mappings, ils peuvent se retrouver en concurrence sur les mêmes verrous, ce qui peut générer des contentions inattendues et compliquer le diagnostic des problèmes.
  4. Mise à jour et déploiement Mettre à jour du code ou des configurations dans plusieurs namespaces nécessite de répéter les opérations, ce qui augmente le risque d’incohérences entre environnements et la charge de travail pour les équipes DevOps.
  5. Surcoût de maintenance Chaque namespace ajoute des tâches de maintenance (monitoring, logs, gestion des utilisateurs, etc.). À grande échelle, cela peut devenir difficile à suivre et à automatiser sans outils adaptés
  6. Difficulté de suivre une trace complète dans Visual Trace : un inconvénient majeur de l’utilisation de plusieurs namespaces, lorsque les flux métier sont liés. Visual Trace ne permet de visualiser que les messages et les transactions d’un seul namespace à la fois. Si un flux métier traverse plusieurs productions réparties sur différents namespaces, il n’est pas possible de visualiser le parcours global du message ou de la transaction dans une seule vue Visual Trace. L’opérateur ou le développeur doit ouvrir séparément chaque namespace dans le Management Portal, puis rechercher manuellement les messages correspondants (souvent avec des identifiants différents ou des métadonnées partielles), ce qui rend le diagnostic et l’analyse chronologique beaucoup plus complexes. Il n’existe pas de corrélation automatique des traces entre namespaces : chaque Visual Trace est limité à l’espace de noms courant, sans suivi transversal natif. Dès lors que des flux d’intégration sont distribués sur plusieurs namespaces, la traçabilité globale via Visual Trace devient morcelée, ce qui complique considérablement le support, la maintenance et l’investigation des incidents métier.

Isolation des processus 

L’isolation des processus dans chaque espace de noms (namespace) InterSystems IRIS est un sujet important pour la sécurité, la stabilité et la gestion de vos applications. Voici une explication détaillée :

1. Qu’est-ce qu’un namespace dans IRIS ?

Un namespace est un environnement logique qui regroupe :

  • Une ou plusieurs bases de données (globals, routines)
  • Des mappings de code et de données
  • Des configurations spécifiques (services, productions, etc.)

2. Isolation des processus : ce qui est isolé

a. Espace d’adressage des données

  • Chaque namespace a ses propres mappings de bases de données.
  • Les globals et routines sont isolés par défaut : un processus dans le namespace A n’accède pas aux données du namespace B (sauf si mapping explicite).

b. Contexte d’exécution

  • Les processus lancés dans un namespace (par exemple, un job d’intégration, une session terminal, un service REST) s’exécutent dans le contexte de ce namespace.
  • Les variables système, le $namespace courant, et les paramètres de session sont propres à chaque processus et à chaque namespace.

c. Productions d’interopérabilité

  • Les productions (Ensemble/IRIS Interoperability) sont isolées par namespace : chaque namespace a sa propre production, ses propres Business Services, Processes et Operations.
  • Les queues, logs, et messages sont séparés.

d. Sécurité

  • Les droits d’accès (Rôle, Ressource) peuvent être définis par namespace.
  • Les utilisateurs peuvent être limités à certains namespaces via la configuration des applications web/services.

3. Ce qui n’est PAS isolé

  • Processus système : Les processus système (ex : le démon d’écriture, le garbage collector) sont globaux à l’instance IRIS.
  • Caches partagés : Le cache de routines et de données est partagé entre tous les namespaces.
  • Mémoire partagée (gmheap) : Les structures internes sont communes.
  • Journalisation (Write Image Journal, Journaux d’audit) : Certains fichiers de journalisation sont globaux.

4. Exemple pratique

  • Si vous lancez un job dans le namespace A, il ne voit que les données et le code de A (sauf mapping).
  • Si un processus dans le namespace B plante, il n’impacte pas directement les jobs du namespace A.
  • Les productions d’interopérabilité ne partagent pas leurs queues ou messages.

5. Limites de l’isolation

  • Processus : Tous les processus sont visibles dans la vue système (^%SS, Management Portal), quel que soit leur namespace d’origine.
  • Ressources système : Les processus de tous les namespaces consomment la même mémoire, CPU et I/O disque.

6. Résumé

Élément Isolé par namespace Global à l’instance
Données (globals) ✔️  
Code (routines/classes) ✔️  
Productions interop ✔️  
Processus système   ✔️
Caches (données/routines)   ✔️
Mémoire partagée   ✔️
Journalisation   ✔️

L’isolation des processus dans chaque namespace est forte sur le plan applicatif (données, code, productions), mais partielle sur le plan système (ressources partagées). Pour une isolation maximale, il faut combiner la séparation par namespace avec des politiques de sécurité et, si nécessaire, des instances IRIS séparées.


En conclusion, une architecture multi-namespaces est préférable pour des flux hétérogènes nécessitant une isolation forte, malgré une complexité opérationnelle accrue. Pour des flux homogènes, un namespace unique avec scaling vertical (CPU/mémoire) peut suffire.

Sylvain Guilbaud · Mai 30, 2025 accéder à la publication

Bonjour Cécile,

L'erreur "BP completion cleanup error deleting BP instance" dans InterSystems IRIS survient généralement lors de la suppression d'une instance de Business Process (BP) après son exécution.
Si le BP est configuré avec PoolSize=0, l'action de suppression des instances peut échouer car le système ne peut pas contrôler tous les threads simultanés.

As-tu plus d'informations dans l'Event Log :  Interoperability > Event Log  ?

Sylvain Guilbaud · Juil 19, 2024 accéder à la publication

MayVilleHop est une plateforme innovante de coordination ville-hôpital développée pour le territoire de la Mayenne, basée sur la solution HealthShare d'InterSystems. Voici une description fonctionnelle et technique de cette plateforme :

Fonctionnalités principales

1. Gestion des demandes semi-urgentes : La plateforme permet aux médecins de ville de soumettre des demandes d'hospitalisation semi-urgentes, avec une réponse garantie sous 48 heures[1][3].

2. Téléexpertise : Un service de téléexpertise est intégré, permettant aux médecins de ville de consulter des spécialistes hospitaliers à distance[1].

3. Espace de discussion : Les professionnels de santé disposent d'un espace dédié pour échanger directement sur la plateforme[1].

4. Accès aux dossiers médicaux : Les utilisateurs peuvent accéder à la synthèse du dossier médical hospitalier du patient ainsi qu'au Dossier Médical Partagé (DMP)[1].

5. Système de notifications : La plateforme envoie des notifications pour chaque événement important du parcours de soins du patient, comme l'admission, l'hospitalisation et la sortie[1].

6. Annuaire des professionnels : Un annuaire des professionnels de santé hospitaliers est intégré à la plateforme[1].

Aspects techniques

1. Authentification sécurisée : Les professionnels de santé se connectent à la plateforme via leur carte CPS, garantissant un accès sécurisé[1].

2. Interopérabilité : HealthShare permet l'interopérabilité entre les différents systèmes d'information de santé, facilitant le partage de données entre la ville et l'hôpital[3].

3. Identification transversale : La plateforme assure une identification sécurisée et transversale des patients dans l'ensemble des systèmes[4].

4. Analyse populationnelle : HealthShare offre des capacités d'analyse des données de santé de la population, permettant d'identifier les besoins en prévention et de notifier les équipes de prise en charge[3].

5. Personnalisation : La plateforme permet une personnalisation de l'utilisation pour les médecins, s'adaptant à leurs besoins spécifiques[2].

6. Sécurité des données : En tant que solution d'InterSystems, HealthShare intègre des fonctionnalités avancées de sécurité pour protéger les données de santé sensibles.

MayVilleHop vise à fluidifier la communication entre l'hôpital et la ville, optimiser le temps médical, et simplifier les parcours de soins complexes. Cette plateforme s'inscrit dans une démarche plus large de transformation numérique du système de santé, contribuant à renforcer le maillage territorial et la collaboration entre les différents acteurs de santé[4].

Citations:
[1] https://www.youtube.com/watch?v=MjlaarmRx98
[2] https://www.esante-paysdelaloire.fr/media-files/4630/le-numerique-en-sa…
[3] https://www.youtube.com/watch?v=cmn1_s7c244
[4] https://emfps.fr/outils-de-coordination-ville-hopital/
[5] https://www.youtube.com/watch?v=wovGmt4ig5Y

Sylvain Guilbaud · Juil 9, 2024 accéder à la publication

Bonjour Moussa,

le messages.log indique une version IRIS 2023.1 :

Si tu utilises ARG IMAGE=intersystemsdc/irishealth-community tu obtiendras une version 2024.1

NB : pour récupérer régulièrement les images plus récentes, le repository officiel InterSystems est https://containers.intersystems.com/contents

Les noms des différentes images régulièrement mises-à-jour sont :
 

EXTENDED_MAINTENANCE=latest-em
CONTINUOUS_DELIVERY=latest-cd
DEVELOPER_PREVIEW=latest-preview
IMAGE_IRIS_EM=containers.intersystems.com/intersystems/irishealth-community:$EXTENDED_MAINTENANCE
IMAGE_IRIS_CD=containers.intersystems.com/intersystems/irishealth-community:$CONTINUOUS_DELIVERY
IMAGE_IRIS_PREVIEW=containers.intersystems.com/intersystems/irishealth-community:$DEVELOPER_PREVIEW

Tu peux utiliser ce repo pour tester les différentes versions d'IRIS for Health :  https://github.com/SylvainGuilbaud/IRISHealth_community 

Sylvain Guilbaud · Juin 6, 2024 accéder à la publication

Bonjour @Julia Pertin 

pour tester un objet dynamique vide tu peux utiliser la méthode d'instance %Size() qui renverra 0

IRISAPP>set monobjet={}

IRISAPP>write monobjet.%Size()
0
IRISAPP>zw monobjet
monobjet={}  ; <DYNAMIC OBJECT>

IRISAPP>set monobjet.data="une valeur"

IRISAPP>write monobjet.%Size()
1
IRISAPP>zw monobjet
monobjet={"data":"une valeur"}  ; <DYNAMIC OBJECT>
Sylvain Guilbaud · Avr 25, 2024 accéder à la publication

Simplement en utilisant l'option Resource dans une instruction CreateDatabase de la section [Actions] du fichier merge.cpf :

[Actions]
CreateResource:Name=%DB_IRISAPP_DATA,Description="IRISAPP_DATA database"
CreateDatabase:Name=IRISAPP_DATA,Directory=/usr/irissys/mgr/IRISAPP_DATA,Resource=%DB_IRISAPP_DATA
CreateResource:Name=%DB_IRISAPP_CODE,Description="IRISAPP_CODE database"
CreateDatabase:Name=IRISAPP_CODE,Directory=/usr/irissys/mgr/IRISAPP_CODE,Resource=%DB_IRISAPP_CODE
CreateNamespace:Name=IRISAPP,Globals=IRISAPP_DATA,Routines=IRISAPP_CODE,Interop=1
Sylvain Guilbaud · Avr 23, 2024 accéder à la publication

Bonjour @Alin Soare,

pouvez-vous nous donner plus de détails sur votre besoin et sur ce que vous ne parvenez pas à faire ?

La commande WRITE fait partie des instructions de base d'IRIS (et même depuis l'origine du langage MUMPS, pré-existant à Caché, Ensemble, IRIS).

Sylvain Guilbaud · Avr 19, 2024 accéder à la publication

Avec le résultat suivant :

python account.py 
Deposit succeeded: Balance after deposit: 100
Deposit of negative amount failed as expected: Deposit amount must be non-negative
Withdrawal succeeded: Balance after withdrawal: 50
Withdrawal of more than available balance failed as expected: Insufficient funds
Balance invariant holds true
Balance invariant violated as expected: Balance invariant violated: Balance is negative
Account operations completed successfully
Sylvain Guilbaud · Avr 19, 2024 accéder à la publication

Exemple en Python :

classAccount:def__init__(self):
        self.balance = 0defdeposit(self, amount):if amount < 0:
            raise ValueError("Deposit amount must be non-negative")
        
        old_balance = self.balance
        self.balance += amount
        
        # Postconditionsif self.balance != old_balance + amount:
            raise ValueError("Postcondition failed: Balance calculation error")

    defwithdraw(self, amount):if amount < 0:
            raise ValueError("Withdrawal amount must be non-negative")
        if self.balance < amount:
            raise ValueError("Insufficient funds")

        old_balance = self.balance
        self.balance -= amount
        
        # Postconditionsif self.balance != old_balance - amount:
            raise ValueError("Postcondition failed: Balance calculation error")

    defcheck_balance_invariant(self):if self.balance < 0:
            raise ValueError("Balance invariant violated: Balance is negative")

    @classmethoddeftest_account(cls):
        account = cls()
        
        try:
            # Test depositing a positive amount
            account.deposit(100)
            print("Deposit succeeded: Balance after deposit:", account.balance)
            
            # Test depositing a negative amount (should fail)
            account.deposit(-50)
        except ValueError as e:
            print("Deposit of negative amount failed as expected:", e)
        else:
            raise ValueError("Deposit of negative amount unexpectedly succeeded")
        
        try:
            # Test withdrawing a valid amount
            account.withdraw(50)
            print("Withdrawal succeeded: Balance after withdrawal:", account.balance)
            
            # Test withdrawing more than the available balance (should fail)
            account.withdraw(200)
        except ValueError as e:
            print("Withdrawal of more than available balance failed as expected:", e)
        else:
            raise ValueError("Withdrawal of more than available balance unexpectedly succeeded")
        
        try:
            # Check balance invariant (should succeed)
            account.check_balance_invariant()
            print("Balance invariant holds true")
        except ValueError as e:
            print("Balance invariant violated:", e)
        
        # Intentionally set balance to negative value to trigger balance invariant failure
        account.balance = -10try:
            # Check balance invariant (should fail)
            account.check_balance_invariant()
        except ValueError as e:
            print("Balance invariant violated as expected:", e)
        else:
            raise ValueError("Balance invariant unexpectedly held true")
        
        print("Account operations completed successfully")

# Run the test
Account.test_account()
Sylvain Guilbaud · Avr 19, 2024 accéder à la publication

Avec le résultat suivant :

write##class(MyApp.Account).TestAccount()
Deposit succeeded: Balance after deposit: 100
Deposit of negative amount failed as expected: ERROR #5001: Deposit amount must be non-negative
Withdrawal succeeded: Balance after withdrawal: 50
Withdrawal of more than available balance failed as expected: ERROR #5001: Insufficient funds
Balance invariant holds true
Balance invariant violated as expected: ERROR #5001: Balance invariant violated: Balance is negative
Account operations completed successfully
1
Sylvain Guilbaud · Avr 19, 2024 accéder à la publication

Exemple en ObjectScript

Include %occErrorsClass MyApp.Account Extends%Persistent
{

Property Balance As%Numeric;/// Deposit money into the account
Method Deposit(amount As%Numeric) As%Status
{
    // PreconditionsIf amount < 0 {
        Return$$$ERROR($$$GeneralError, "Deposit amount must be non-negative")
    }

    // Store the old balanceSet oldBalance = ..Balance// Update balanceSet..Balance = oldBalance + amount

    // PostconditionsIf (..Balance '= $$$NULLOREF) && (..Balance '= (oldBalance + amount)) {
        Return$$$ERROR($$$GeneralError, "Postcondition failed: Balance calculation error")
    }

    Quit$$$OK
}

/// Withdraw money from the account
Method Withdraw(amount As%Numeric) As%Status
{
    // PreconditionsIf amount < 0 {
        Return$$$ERROR($$$GeneralError, "Withdrawal amount must be non-negative")
    }
    If (..Balance = $$$NULLOREF) || (..Balance < amount) {
        Return$$$ERROR($$$GeneralError, "Insufficient funds")
    }

    // Store the old balanceSet oldBalance = ..Balance// Update balanceSet..Balance = oldBalance - amount

    // PostconditionsIf (..Balance '= $$$NULLOREF) && (..Balance '= (oldBalance - amount)) {
        Return$$$ERROR($$$GeneralError, "Postcondition failed: Balance calculation error")
    }

    Quit$$$OK
}

/// Invariant: Balance should always be non-negative
Method CheckBalanceInvariant() As%Status
{
        Set tSC = $$$OKIf..Balance < 0 {
            Set tSC = $$$ERROR($$$GeneralError, "Balance invariant violated: Balance is negative")
        }
        Quit tSC
}

/// Class method to test the Account classClassMethod TestAccount() As%Status
{
    // Create a new instance of AccountSet account = ##class(MyApp.Account).%New()
    
    // Initialize the balanceSet account.Balance = 0// Test depositing a positive amountSet tSC = account.Deposit(100)
    If$$$ISERR(tSC) {
        Write"Deposit failed: ", $system.Status.GetErrorText(tSC), !
        Quit tSC
    }
    Write"Deposit succeeded: Balance after deposit: ", account.Balance, !
    
    // Test depositing a negative amount (should fail)Set tSC = account.Deposit(-50)
    If$$$ISERR(tSC) {
        Write"Deposit of negative amount failed as expected: ", $system.Status.GetErrorText(tSC), !
    } Else {
        Write"Deposit of negative amount unexpectedly succeeded", !
        Quit$$$ERROR($$$GeneralError, "Deposit of negative amount unexpectedly succeeded")
    }
    
    // Test withdrawing a valid amountSet tSC = account.Withdraw(50)
    If$$$ISERR(tSC) {
        Write"Withdrawal failed: ", $system.Status.GetErrorText(tSC), !
        Quit tSC
    }
    Write"Withdrawal succeeded: Balance after withdrawal: ", account.Balance, !
    
    // Test withdrawing more than the available balance (should fail)Set tSC = account.Withdraw(200)
    If$$$ISERR(tSC) {
        Write"Withdrawal of more than available balance failed as expected: ", $system.Status.GetErrorText(tSC), !
    } Else {
        Write"Withdrawal of more than available balance unexpectedly succeeded", !
        Quit$$$ERROR($$$GeneralError, "Withdrawal of more than available balance unexpectedly succeeded")
    }
    
    // Check balance invariant (should succeed)Set tSC = account.CheckBalanceInvariant()
    If$$$ISERR(tSC) {
        Write"Balance invariant violated: ", $system.Status.GetErrorText(tSC), !
        Quit tSC
    }
    Write"Balance invariant holds true", !
    
    // Intentionally set balance to negative value to trigger balance invariant failureSet account.Balance = -10// Check balance invariant (should fail)Set tSC = account.CheckBalanceInvariant()
    If$$$ISERR(tSC) {
        Write"Balance invariant violated as expected: ", $system.Status.GetErrorText(tSC), !
    } Else {
        Write"Balance invariant unexpectedly held true", !
        Quit$$$ERROR($$$GeneralError, "Balance invariant unexpectedly held true")
    }
    
    Write"Account operations completed successfully", !
    Quit$$$OK
}

Storage Default
{
<Data name="AccountDefaultData">
<Value name="1">
<Value>%%CLASSNAME</Value>
</Value>
<Value name="2">
<Value>Balance</Value>
</Value>
</Data>
<DataLocation>^MyApp.AccountD</DataLocation>
<DefaultData>AccountDefaultData</DefaultData>
<IdLocation>^MyApp.AccountD</IdLocation>
<IndexLocation>^MyApp.AccountI</IndexLocation>
<StreamLocation>^MyApp.AccountS</StreamLocation>
<Type>%Storage.Persistent</Type>
}

}
Sylvain Guilbaud · Mars 18, 2024 accéder à la publication

Bienvenue à IRIS 2024 !!


Chez un de nos clients, la nouvelle fonctionnalité des bases de données multi-volumes a notamment permis de pallier la contrainte de la taille des fichiers sur leur serveur de stockage en réseau (NAS) limitée à 4To.

Le portail  System > Databases > Database Details permet de voir les différents volumes créés ; ici avec un seuil à 15Mo : 

Extrait de la documentation en ligne :

À mesure que les bases de données clients se développent, les fichiers de bases de données évoluent également. Pour éviter que ces fichiers ne deviennent trop volumineux ou n'atteignent les limites strictes du système de fichiers, InterSystems IRIS prend désormais en charge la division transparente de votre base de données sur plusieurs « volumes » physiques. Cette nouvelle fonctionnalité se configure facilement : pour n'importe quelle base de données, vous pouvez désormais configurer une taille de seuil. Lorsque votre fichier IRIS.DAT initial est sur le point d'atteindre cette taille et que de nouvelles données globales doivent être écrites, InterSystems IRIS créera de manière transparente un nouveau fichier « volume de base de données » et commencera à écrire de nouvelles données dans ce fichier. Lorsque ce volume atteint le seuil, un autre fichier est créé, et ainsi de suite.

Il n'y a aucun impact sur les applications et le code qui accèdent aux données, car ils continuent de voir le contenu complet de la base de données, quel que soit le nombre de volumes sur lesquels elle est répartie. De plus, vous pouvez configurer le répertoire dans lequel le prochain volume doit être créé et, si nécessaire, vous pouvez réorganiser les volumes de base de données dans les répertoires en tant qu'opération de maintenance. Combiné aux travaux prévus pour augmenter la taille maximale globale de la base de données, cela garantira que vos données restent faciles à gérer, bien dans la plage des pétaoctets.

Sylvain Guilbaud · Fév 7, 2024 accéder à la publication

Merci à @Vitaliy Serdtsev : il est aussi possible de récupérer directement un JSON à partir d'une requête SQL, avec les fonctions JSON_ARRAYAGG et JSON_OBJECT :

SELECT JSON_ARRAYAGG(json_obj)
  FROM (SELECT TOP 5
            JSON_OBJECT(
              'Name':name
              ,'Age':age
              ,'DOB':to_char(dob,'Day DD Month YYYY')
            ) json_obj
           FROM sample.person
       )
SELECT JSON_ARRAYAGG(json_obj)
  FROM (SELECT JSON_OBJECT(
                'Name':name
                ,'Age':age
                ,'DOB':to_char(dob,'Day DD Month YYYY')
                ) json_obj
       FROM sample.person
       )
  WHERE %VID BETWEEN 1 AND 5

Résultat :

 

Sylvain Guilbaud · Jan 25, 2024 accéder à la publication

Bonjour @Jean-Charles Cano 
si ton service FTP ne doit s'exécuter qu'une seule fois par jour, à une heure bien précise, la planification est effectivement le bon moyen, en veillant à ce que l'intervalle entre appel soit supérieur à la durée séparant l'heure du START et celle du STOP.

L'autre moyen, sans planification, est de simplement mettre un intervalle entre appels de 86400 pour obtenir un appel une seule fois par jour. L'inconvénient ici étant que le service restera démarré 24h/24h sans utilité.