Diagnostiquer une application declarative

Statut documentaire : guide — voir Maturité et preuves.

Le diagnostic part de la chaine de dependances du modele, pas du corps du script.

Ordre de diagnostic

configuration application
  -> activation package
  -> presence dans le manifest
  -> compilation modele
  -> enregistrement conceptuel
  -> creation objet
  -> provider de collection
  -> binding action
  -> routage evenement
  -> curseur de vue et DataSets
  -> persistance
  -> publication/service

Si un modele n'apparait jamais dans les logs de compilation, verifier configuration, package, schema path et manifest. S'il n'existe pas d'Entity record, verifier la declaration conceptuelle Entity, pas seulement type: Entity. Si aucune polyadic map n'est construite, verifier l'enregistrement semantique et la compatibilite des roles positifs. En cas de classId duplique, inspecter tous les packages et manifests actifs.

Smoke test

sclgc -c <path-to-application.lgc>

Lire ensuite le log dans l'ordre : application, package, manifest, modele, collections, initialisation semantique, demarrage Runtime. S'arreter au premier niveau ou le module attendu disparait.

Des paires d'options utiles sont --debug / -dbg, --log-level / -ll, --test / -t, --test-out / -to, --modules / -m et --services / -sg. Verifier leur disponibilite sur le Runtime cible avant automatisation.