Nouveau module SQLite pour PowerShell
De retour tout juste de PSConfEU, j’ai publié
synedgy.PSSQlite :
un module destiné à simplifier la persistance SQLite dans les modules PowerShell.

Pourquoi SQLite pour l’automatisation
SQLite est une option pratique pour la persistance locale et la mise en cache :
- Format de base de données en un seul fichier
- Performances suffisantes pour de nombreux scénarios de modules
- Opérations de sauvegarde et de restauration simples
- Faible charge d’exploitation
C’est particulièrement utile pour les données locales d’un module ou les caches légers, par exemple la mise en cache de données PowerShell Universal.
Limites de SQLite à garder en tête
- Le système de types de SQLite est volontairement simple (
INTEGER,REAL,TEXT,BLOB,ANY). - Les écritures concurrentes peuvent entrer en conflit, car les écritures verrouillent le fichier de base de données.
- Ce n’est pas un remplacement universel pour des charges relationnelles plus lourdes.
Dans le contexte des modules, ces compromis sont souvent acceptables, notamment pour l’état local, les caches et les magasins de données légers.
Pourquoi créer synedgy.PSSqlite
synedgy.PSSqlite réduit les freins à l’adoption en permettant des opérations
CRUD sans imposer à chaque consommateur d’écrire du SQL brut pour les flux
courants.
Deux choix de conception dans cette implémentation :
- Utiliser
Microsoft.Data.Sqliteplutôt queSystem.Data.SQLite - Conserver un chemin sans SQL pour les opérations CRUD courantes
Le jeu de commandes principal :
Get-PSSqliteRowNew-PSSqliteRowSet-PSSqliteRowRemove-PSSqliteRow
Persistance SQL sans écrire du SQL partout
Dans le module d’exemple, Get-Car transmet $PSBoundParameters à
Get-PSSqliteRow en tant que ClauseData :
function Get-Car {
[CmdletBinding()]
param(
[string]$Make,
[string]$Model,
[string]$Colour,
[int]$Year
)
$getPSSqliteRowParams = @{
SqliteDBConfig = (Get-myModuleConfig)
TableName = 'Cars'
ClauseData = $PSBoundParameters
Verbose = $Verbose.IsPresent -or $VerbosePreference -in @('Continue', 'Inquire')
}
Get-PSSqliteRow @getPSSqliteRowParams
}
L’exécution de Get-Car -Colour yellow -Verbose génère du SQL paramétré et
renvoie les lignes correspondantes :

Configuration pilotée par schéma
Le module utilise une configuration adossée à YAML pour décrire :
- Le chemin et le fichier de base de données
- Les définitions de tables
- Les métadonnées et contraintes de colonnes
# ./config/myModule.PSSqliteConfig.yml
DatabasePath: $repository
DatabaseFile: test.db
version: 0.0.3
Schema:
Tables:
cars:
columns:
id:
type: INTEGER
PrimaryKey: true
indexed: true
make:
type: TEXT
model:
type: TEXT
colour:
type: TEXT
year:
type: INTEGER

Avec ce schéma, le module peut générer les instructions SQL et initialiser les objets de base de données de manière répétable.

Appeler du SQL personnalisé quand c’est nécessaire
Le module expose toujours Invoke-PSSqliteQuery pour le SQL direct lorsque
c’est nécessaire :
$dbconfig = Get-PSSqliteDBConfig -Path .\myModule\config\myModule.PSSqliteConfig.yml
$conn = New-PSSqliteConnection -ConnectionString $dbconfig.ConnectionString
Invoke-PSSqliteQuery `
-SqliteConnection $conn `
-CommandText 'SELECT * FROM cars WHERE colour LIKE @colour' `
-Parameters @{ colour = 'Yel%' }
Pratiques utiles en production
Quelques habitudes pratiques aident en production :
- Mettre en cache l’objet de configuration chargé dans la portée du module
- Gérer explicitement la durée de vie des connexions (
-KeepAliveseulement quand c’est utile) - S’appuyer sur du SQL paramétré pour des requêtes plus sûres

Conclusion
synedgy.PSSqlite vise à donner aux auteurs de modules une valeur par défaut
pragmatique : une persistance pilotée par schéma et des commandes CRUD simples,
avec une voie de sortie vers du SQL personnalisé chaque fois que nécessaire.