API non fonctionnelle sur des objets métier de type select

Bonjour
Nous avons un objet métier “IT4ITProductStructuralUnit” de type select.
Cet objet est exposé avec les droits en lecture dans notre swagger.

		addObject("productsStructuralUnits", "IT4ITProductStructuralUnit");
		addField("productsStructuralUnits", "id", "row_id");
		addRefField("productsStructuralUnits", "productId", "productId", "it4itGenProductId", "Id of the product");
		// addField("productsStructuralUnits", "productIdentifier", "it4itGenProductId.it4itGenIdentifier", "Identifier of the product", null);
		// addField("productsStructuralUnits", "productName", "it4itGenProductId.it4itGenName", "Name of the product", null);
		addRefField("productsStructuralUnits", "structuralUnitId", "structuralUnitId", "it4itStructuralUnitId", "Id of the structural unit where belongs the delivery team");
		addField("productsStructuralUnits", "structuralUnitIdentifier", "it4itStructuralUnitId.it4itGenIdentifier", "Identifier of the structural unit where belongs the delivery team", null);
		addField("productsStructuralUnits", "structuralUnitName", "it4itStructuralUnitId.it4itGenName", "Name of the structural unit where belongs the delivery team", null);
		addRefField("productsStructuralUnits", "products", "productId", "it4itGenProductId", "belongsTo", true, "Structural unit where the product belongs");

Lorsque l’on récupère la liste on obtient,

{
  "productsStructuralUnits": [
    {
      "productId": "6",
      "structuralUnitIdentifier": "SU1",
      "structuralUnitId": "10",
      "id": "1",
      "structuralUnitName": "Structural unit 1"
    },
    {
      "productId": "6",
      "structuralUnitIdentifier": "SU2",
      "structuralUnitId": "11",
      "id": "2",
      "structuralUnitName": "Structural unit 2"
    }
  ]
}

Lorsqu’on essaie d’appeler un élément en particulier, par exemple id : 1

{
  "productId": "",
  "structuralUnitIdentifier": "",
  "structuralUnitId": "",
  "id": "",
  "structuralUnitName": ""
}

Je devine que cela ne fonctionne pas car il s’agit d’un objet non persisté et donc que le id indiqué dans la liste n’est pas vraiment un row_id.

Est-il possible soit de supprimer la création de cette méthode GET/id ou de la corriger afin que le retour soit “cohérent” ? (Nous préférerions la suppression de la création cf : API : Exposition une ressource au sein d’une autre ressource sans exposition autonome )

Merci d’avance

[Platform]
Status=OK
Version=4.0.P24
BuiltOn=2020-02-26 22:59 (revision ff84cba0fa5c6a06fda80f27b41502439d1ac3a0)
Encoding=UTF-8
EndpointIP=172.17.0.16
EndpointURL=http://af5bb7d86a98:8080
TimeZone=Europe/Paris
SystemDate=2020-02-28 16:58:02

Oui dans un objets “select” (et des objets “distincts”) il n’y a pas de “vrai” row ID.

Le moteur en met un pour que la “mécanique” fonctionne mais il ne correspond pas à un identifiant de record, c’est juste un numéro de ligne attribué de manière éphémère aux records ramenés par le requête.

Autrement dit un record d’un objet select ne peut conceptuellement pas être identifié par un row ID mais par des critères de recherche. C’est pour la même raison qu’on ne peut pas créer, référencer, updater, supprimer un record d’un objet select.

Pour le cas du mapping d’un objet “select” (qui n’est pas un cas prévu par ce composant) il faudrait donc masquer ce pseudo row ID et la méthode get unitaire car elle n’a pas de sens pour ce genre d’objet

Avez-vous une solution pour le masquer ?

Non pas en l’état.

Prendre en compte le cas particulier des objets select dans le mapping est une évolution (d’ailleurs j’ai requalifié le post en feature request) qu’on va traiter. On vous tiendra au courant.

OK l’évolution est faite: le mappings des objets select ne contiendront plus d’attribut row ID et n’exposeront plus que l’opération search, les autres opérations get/create/update/delete n’ayant pas de sens pour ce type d’objet.

Cette évolution sera backportée en P24

Quelle réactivité !! Merci beaucoup. Savez vous quand cette évolution sera back portée ?

1 Like

C’est fait, les images Docker son à jour