2 bugs lors d'un PUT en LDP

[srosset81]

Rapporté par @VincentFarcy:

Bug 1

Si je crée 2 plages horaires d'un coup pour le même champ, j'ai une erreur 500

PUT, request payload :

petr:openingTimesDay1: [
 {petr:startingTime: "2021-10-07T08:47:35.600Z", petr:endingTime: "2021-10-07T10:47:35.607Z"},
 {petr:startingTime: "2021-10-07T12:47:46.714Z", petr:endingTime: "2021-10-07T16:47:46.717Z"}
]

Erreur:

INSERT { <http://localhost:3000/organizations/orga1> <http://petr.org#openingTimesDay1> ?openingTimesDay1 .
 <http://localhost:3000/organizations/orga1> <http://petr.org#openingTimesDay1> ?openingTimesDay1 .
 ?openingTimesDay1 <http://petr.org#endingTime> '''2021-10-07T14:00:33.577Z''' .
 ?openingTimesDay1 <http://petr.org#startingTime> '''2021-10-07T11:15:33.572Z''' .
 ?openingTimesDay1 <http://petr.org#endingTime> '''2021-10-07T09:00:12.151Z''' .
 ?openingTimesDay1 <http://petr.org#startingTime> '''2021-10-07T06:15:12.140Z''' . } WHERE { ?hasLocation <http://virtual-assembly.org/ontologies/pair#hasPostalAddress> ?hasPostalAddress .
 <http://localhost:3000/organizations/orga1> <http://virtual-assembly.org/ontologies/pair#hasLocation> ?hasLocation .BIND (BNODE() AS ?openingTimesDay1) .
 BIND (BNODE() AS ?openingTimesDay1) . }
 BIND: Variable used when already in-scope: ?openingTimesDay1 in BIND(bnode() AS ?openingTimesDay1)

Bug 2

Si je crée d'abord 1 seule plage, le résultat est bon:

PUT, request payload :

petr:openingTimesDay1: [{petr:startingTime: "2021-10-07T06:40:56.123Z", petr:endingTime: "2021-10-07T09:40:56.131Z"}]

GET

"petr:openingTimesDay1": {
"petr:endingTime": "2021-10-07T09:40:56.131Z",
"petr:startingTime": "2021-10-07T06:40:56.123Z"
}

Par contre ça bugge si j'ajoute un deuxième élément:

PUT, request payload :

petr:openingTimesDay1: [
 {petr:endingTime: "2021-10-07T09:40:56.131Z", petr:startingTime: "2021-10-07T06:40:56.123Z"},
 {petr:startingTime: "2021-10-07T10:44:54.883Z", petr:endingTime: "2021-10-07T16:44:54.888Z"}
]

GET

"petr:openingTimesDay1": {
"petr:endingTime": [
"2021-10-07T16:44:54.888Z",
"2021-10-07T09:40:56.131Z"
],
"petr:startingTime": [
"2021-10-07T10:44:54.883Z",
"2021-10-07T06:40:56.123Z"
]

Dans ce cas c'est bien enregistré mais avec une structure inadaptée.

Ping @simonLouvet

[fluidlog]

Est-ce vraiment une "high priority" ? @simonLouvet, peux-tu donner ton avis là dessus ? Merci :) Ping @VincentFarcy

[simonLouvet]

oui cela bloque des développements notamment pour PETR Sub Bourgogne. c'est @BastienSig qui travaille dessus

[simonLouvet]

linked to #893