Bonjour,
Dans le cadre d’un héritage, j’observe une différence de comportement entre la v4 et la v5 sur la prise en compte du filtre obo_searchspec (forçant le filtre sur le sous-type de l’héritier) qui n’est plus appliqué lors des imports XML.
J’ai essayé de restaurer le comportement initial en ajoutant explicitement un setSearchSpec(getDefaultSearchSpec()+"…") dans le preSearch mais ça n’est pas pris en compte dans le cadre des imports XML.
@Override
public void preSearch() {
/*
** DEBT: obo_searchspec lost in translation
*/
if (!getSearchSpec().contains(getDefaultSearchSpec())) {
warn("preSearch", "DEBT/obo_searchspec lost in translation getSearchSpec="+getSearchSpec(), this);
setSearchSpec(getDefaultSearchSpec()+" AND "+getSearchSpec());
}
/**/
}
Ca ne me dit rien, les objets dédiés aux imports n’ont pas de choses particulières, la définition est la même que les autres objets. L’instance est juste différente pour permettre de faire des choses particulières lors d’un traitement de masse (généralement passer des contrôles UI/API, ne pas envoyer des mails…).
Y a-t-il des isBatchInstance dans votre code pour faire des choses particulières dans l’objet père ou hérité ?
Merci beaucoup pour ton retour rapide.
Non, rien de ce type…
Il s’agit d’un héritage de FieldListCode pour ouvrir la création des codes et la gestion des traductions aux administrateurs métier → les usecases pourraient être refondus (et les objets métier concernés désinvestis) en utilisant les nouveaux composants “matrices de traductions” (mais je n’ai pas prévu de faire cela maintenant).
Les opérations standard fonctionnent comme avant. C’est juste l’import XML qui plante sur REF_AMBIGUOUS car il manque une partie de la searchspec.
Un héritage d’un objet socle codé en Java
extends com.simplicite.objects.System.FieldListCode ?
Cet objet ne fait rien de bien méchant.
La résolution d’un FK en V5 a aussi effectivement changée quand c’est ambigu (clé partielle).
Avant Simplicité prenait le premier trouvé mais ça générait d’autres effets.
Ce problème existait peut être avant mais était passant.
Et forcer un setDefaultSearchSpec(...) juste dans le postLoad ?
ça doit être ça…
J’ai essayé mais ce n’est pas pris en compte lors de l’import XML.
En fait, le getDefaultSearchSpec renvoie bien le filtre mais il n’est pas appliqué.
Je pense que la bonne piste est peut-être de réintégrer la clé complète de l’hérité dans l’héritier car le searchspec sert justement à cloisonner les options des sous-types (héritiers).
Mais comme c’est une partie du modèle que je souhaite désinvestir, tant que j’ai un scénario nominal qui fonctionne, je laisse de côté (et l’import XML ne sert qu’à nous pour préparer des environnements).
Merci pour tes explications.
Ok merci pour l’analyse.
ça confirme donc la piste initiale (je dois compléter les clés dans l’héritier pour que les exports XML soient complets).
Merci encore!