Lors de la sauvegarde de template, on ne valide pas qu'une propriété simple ne doit pas avoir le même nom qu'une propriété itérable

[lenaing]

Exemple de template:

{{#appenders.file-rolling-vsctlayout}}
    <appender class="ch.qos.logback.core.rolling.RollingFileAppender" name="{{appendername}}">
        <File>${log.instance.dir}/espaceclient/{{filename}}.log</File>
        <Append>true</Append>
        <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
            <maxFileSize>{{roll.threshold|@comment "taille du fichier déclenchant une rotation (kilo-octet)" @default 5000}}KB</maxFileSize>
        </triggeringPolicy>
        <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy">
            <fileNamePattern>${log.instance.dir}/espaceclient/{{filename}}.log-%i</fileNamePattern>
            <maxIndex>{{roll.max-index|@comment "nombre maximal de fichiers '.log-%i'" @default 5}}</maxIndex>
        </rollingPolicy>
        <Encoder class="ch.qos.logback.core.encoder.LayoutWrappingEncoder">
            <layout class="com.vsct.component.log.layout.logback.VsctLayout"/>
        </Encoder>
    </appender>
{{/appenders.file-rolling-vsctlayout}}

Mon iterable : {{appenders.file-rolling-vsctlayout}}

Stacktrace:

2019-07-18 15:29:53.376 ERROR 11312 --- [nio-8080-exec-5] o.h.c.p.e.GlobalExceptionHandler         : Unexpected error (path=uri=/rest/applications/KTN/platforms/KTN1/properties):
2019-07-18 15:29:53.378 ERROR 11312 --- [nio-8080-exec-5] o.h.c.p.e.GlobalExceptionHandler         : java.lang.ClassCastException: org.hesperides.core.domain.templatecontainers.queries.PropertyView cannot be cast to org.hesperides.core.domain.templatecontainers.queries.IterablePropertyView

java.lang.ClassCastException: org.hesperides.core.domain.templatecontainers.queries.PropertyView cannot be cast to org.hesperides.core.domain.templatecontainers.queries.IterablePropertyView
    at org.hesperides.core.domain.platforms.queries.views.properties.IterableValuedPropertyView.excludePropertyWithOnlyDefaultValue(IterableValuedPropertyView.java:59)
    at org.hesperides.core.domain.platforms.queries.views.properties.AbstractValuedPropertyView.lambda$excludePropertiesWithOnlyDefaultValue$2(AbstractValuedPropertyView.java:88)

[Lucas-C]

Cette vérification pourrait être faite dans PlatformUseCases.getValuedProperties, avant l'appel à excludePropertiesWithOnlyDefaultValue qui lève cette exception

Réflexion faite, on veut détecter ce cas lors des opérations de création de template / MAJ de template

[Lucas-C]

Il serait très intéressant d'avoir un test BDD pour ce type de cas, car c'est un "trou dans la raquette" du même type que ceux identifiés dans https://github.com/voyages-sncf-technologies/hesperides/issues/705 &https://github.com/voyages-sncf-technologies/hesperides/issues/648 & https://github.com/voyages-sncf-technologies/hesperides/issues/505 & https://github.com/voyages-sncf-technologies/hesperides/issues/89

[Lucas-C]

Petite analyse des modifications à apporter pour corriger ce bug "proprement" (validée avec @thomaslhostis) :

• en termes de design DDD, cette validation devrait avoir lieu dans ModuleAggregate.onCreateTemplateCommand/.onUpdateTemplateCommand
• cela implique de remonter la logique d'extractions des propriétés actuellement faite dans la couche infrastructure (ModuleDocument.extractPropertiesAndSave) dans la couche domaine (en ajoutant un champ Module.properties)
• cela implique également de modifier les commands / events CreateTemplate / UpdateTemplate pour qu'ils contiennent l'entitié Module au complet

[Lucas-C]

CR de notre discussion là-dessus à l'instant avec @thomaslhostis & @lenaing

• ce refacto implique de faire "grossir" CreateTemplateCommand & TemplateCreatedEvent, en leur ajoutant un minima un champ .properties. Est-ce vraiment souhaitable ? Le bénéfice en termes de clarté de code vaut-il une telle augmentation de la volumétrie de données ?

• ce sujet en tire un autre important : comme gérer l'évolution du schéma des commands & events du bus ? Dans le cas de l'ajout d'un champ .properties à TemplateCreatedEvent par exemple, cela signifie que le code doit être capable de gérer à la fois les anciens événements sans ce champ et les nouveaux l'ayant ? Ou bien faut-il envisager une migration de tous les événements historiques pour leur rajouter ce champ ?

tl,pl : refacto trop couteux en temps à réaliser, et "risqué" en terme d'impact -> on n'attaque pas le sujet maintenant

Issue dédiée : https://github.com/voyages-sncf-technologies/hesperides/issues/744