Aller au contenu principal

AUSUS v1.1.0 — relations, autorisation dépendante des données & PostgreSQL

Version mineure et rétrocompatible sur la ligne 1.x. Elle ajoute trois capacités — des relations typées avec intégrité référentielle, une autorisation dépendante des données, et un driver PostgreSQL officiel de production — et livre tous les paquets en lock-step à la version v1.1.0. Les consommateurs existants en ^1.0 avancent automatiquement avec composer update, sans changement de code.

Relations et intégrité référentielle (RFC-015)​

Les entités peuvent désormais déclarer des références étrangères typées vers d'autres entités, avec une intégrité appliquée à la fois à la construction et à l'écriture.

$dsl->entity('claim')
    ->fields([
        'policy_id' => Field::reference('claims.policy'),
        // …
    ]);
  • Contrôle à la compilation. Une référence vers une entité cible inexistante est rejetée à la compilation du graphe de métadonnées — pas de référence fantôme dans un graphe qui compile.
  • Application à l'écriture. Créer ou mettre à jour une ligne dont la référence pointe vers un parent manquant lève ReferentialIntegrityViolation.
  • Expansion de projection. Une projection peut replier le champ d'affichage d'une ligne référencée dans sa sortie via expand.

L'objet-valeur d'identité Subject est unifié dans Reference (conservé comme alias rétrocompatible).

Autorisation dépendante des données (RFC-018)​

L'autorisation peut désormais lire l'enregistrement concerné et des attributs d'acteur structurés — pas seulement les rôles. La règle dont a réellement besoin un domaine sinistres, KYC, risque fournisseur ou finance (« approuver seulement jusqu'à sa limite d'autorité ») s'exprime comme un garde, évalué avant tout effet et en mode fermé.

$dsl->actorAttributes(['authority_limit' => Field::integer()]);

'approve' => Action::transition('status', from: 'ASSESSING', to: 'APPROVED')
    ->requireRole('claims.adjuster')
    ->requireThat(Cond::lte(Fact::subject('claim_amount'), Fact::actor('authority_limit'))),
  • Facts. Fact::subject(field) lit un champ de l'entité sujet chargée ; Fact::actor(attribute) lit un attribut d'acteur structuré ; Fact::input(key) lit une entrée d'action.
  • Conditions. Cond::eq / ne / lt / lte / gt / gte / in, composées avec and / or / not.
  • Fermeture à la compilation. Un garde référençant un champ sujet, un attribut d'acteur ou une entrée inconnus est rejeté à la compilation (DanglingFactReference).
  • Runtime. Le sujet est chargé avant l'autorisation ; le garde s'exécute dans la transaction de l'action ; un refus se manifeste par PolicyDenied (HTTP 403) et annule la transaction.

Les politiques basées sur les rôles ne sont pas affectées — requireRole continue de fonctionner exactement comme avant.

Driver PostgreSQL de production (ausus/persistence-postgres)​

Un nouveau PersistenceDriver L3 officiel amène AUSUS sur la base de données sur laquelle tournent les systèmes d'entreprise, derrière le même contrat que la référence SQLite.

composer require ausus/persistence-postgres:^1.1
  • Transactions par tenant et isolation au niveau ligne WHERE tenant_id = ?.
  • Verrouillage optimiste → ConcurrencyConflict, identique au message près à SQLite.
  • Filtrage (eq / contains / in), tri déterministe avec un départage par id, et pagination avec totaux.
  • Application de l'intégrité référentielle RFC-015.
  • Sink d'audit dans la transaction écrivant la table kernel_audit_log à 17 colonnes.

Déplacer une application du driver SQLite de développement vers PostgreSQL en production ne demande aucun changement de domaine — seulement le driver configuré. Testé sur PostgreSQL 16.

Gate de compatibilité inter-drivers​

Une suite de parité inter-drivers dédiée vérifie que les drivers SQLite et PostgreSQL se comportent de façon identique sur l'ensemble du contrat de persistance du kernel — valeurs par défaut, types, références, isolation des tenants, update/concurrence, filtrage/tri/pagination, et forme de l'audit — avec des exceptions identiques au message près.

Elle s'exécute à chaque changement sous forme de workflow CI contre un véritable service postgres:16, avec un garde anti-faux-positif (AUSUS_PG_REQUIRED) qui fait échouer le build à moins que le driver PostgreSQL n'ait réellement participé. Le contrat SQLite ↔ PostgreSQL devient ainsi une propriété vérifiée en continu, et non une affirmation ponctuelle.

État de version lock-step​

Tous les paquets AUSUS sont tagués à v1.1.0 en lock-step et distribués sur Packagist depuis leurs dépôts subtree-split dédiés, ausus/persistence-postgres rejoignant l'ensemble comme nouveau paquet officiel. Les contraintes inter-paquets sont sur la ligne ^1.1.

Paquetv1.1
ausus/kernelsurface relations + guard kernel
ausus/runtime-defaultruntime des gardes dépendants des données
ausus/persistence-sqldriver SQLite de référence
ausus/persistence-postgresdriver PostgreSQL de production (nouveau)
ausus/api-httpprise en charge des attributs d'acteur, fil inchangé
ausus/standard-stackbundle épinglant l'ensemble central
ausus/startermodèle de démarrage rapide

Compatibilité et mise à niveau​

  • SemVer mineur, additif. Aucun changement cassant de l'API publique, du fil HTTP ou du ViewSchema. Le substrat par défaut reste SQLite ; PostgreSQL est opt-in.
  • Mise à niveau depuis 1.0.x. Avancez avec composer update, ou épinglez ^1.1. Aucun changement applicatif n'est nécessaire pour continuer à fonctionner ; les relations, les gardes dépendants des données et PostgreSQL sont disponibles quand vous choisissez de les adopter.
composer create-project ausus/starter myapp
cd myapp && composer boot

Voir l'aperçu Paquets pour l'ensemble complet des paquets et Concepts pour le modèle, tous deux dans la barre latérale de la documentation.