Filtre obo_searchspec ne semble plus être appliqué (par défaut)

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());
		}
		/**/
	}

Version=5.1.10
BuiltOn=2021-10-21 00:59
Git=release/80f882d651de1e53044367f00a1f1b5e1bf46c6e

Bonsoir,

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, je vais quand même regarder si Simplicité retire les search-spec des objets systèmes à l’import
(pour cause d’import module ou autre…)

Au pire, et si c’est transitoire c’est votre postSearch qui devra filtrer par code les lignes ramenées.

Apres vérification, la searchspec est bien présente même pour un héritier d’un objet system.

Par contre elle ne sert pas à retrouver une FK basée sur les données fournies dans le XML.

Il faut bien que le XML soit complet, les champs inutiles pouvant être juste masqués sur la UI.

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!

This topic was automatically closed 60 minutes after the last reply. New replies are no longer allowed.