Actuellement les fonctions du catalog retournent l'objet sérialisé en JSON. Ce comportement ne sera pas viable si on doit faire du GML. Il faut donc modifier ces fonctions pour qu'elles retournent l'objet à sérialiser. La sérialisation est déléguée à la fonction appelante.

In GitLab by @benoitdm-oslandia on Sep 19, 2022, 16:41

As editor, I want to be sure to have the right version of the data in order to have an integrated collection

• #52
• #36
• #39
• #50
• #48
• #44
• #89
• #78

In GitLab by @benoitdm-oslandia on Oct 10, 2022, 09:44

"Optimistic locking" defines an optimistic locking mechanism to support concurrent resource updates

What if the request does not contain an eTag?

• See the filed issue and this reflection on the implementation

• no if-match ==> error

• #11

• #12

As editor, I want to remove an existing feature in order to clean up collection

• modifier les fichiers markdown dans /
• modifier la doc dans /hugo/

In GitLab by @benoitdm-oslandia on Sep 19, 2022, 09:16

In GitLab by @azarz on Sep 20, 2022, 16:19

Pour l'instant, la grande majorité des codes de retours sont des 500, alors que dans certains cas il me semble que des 400 seraient plus pertinents. Exemples:

https://git.oslandia.net/Client-projects/geoplateforme-ign-pg-featureserv/-/blob/develop/internal/service/handler.go#L354

https://git.oslandia.net/Client-projects/geoplateforme-ign-pg-featureserv/-/blob/develop/internal/service/handler.go#L716

Exemple dans les tests : une requête est volontairement mal formée, mais on s'attend quand même à un 500 :
https://git.oslandia.net/Client-projects/geoplateforme-ign-pg-featureserv/-/blob/develop/internal/service/handler_update_test.go#L251

Dans le cas du replace, j'ai opté pour un 400 dans ce cas là.

"Security" defines how the system checks authentication and permissions

• #14
• #15

test de charge pour calculer le temps pris

• pour lire la donnée
• pour convertir en json
• etc.

Produire des stats pour différentes configurations (nombre de workers, nombre de requetes, etc.)

As editor, I want to have data schemas in geojson in order to know the fields needed to update the collection

• La ci ne passent pas les tests !!
• pre-commit n'est pas installé et beaucoup de d'erreurs statiques pourraient être fixées

Limitation and reduction of transmitted data (Cf. opengeospatial/ogcapi-features#738)

Extensions not validated yet:

• simplification of geometries
  ==> the filtering must be in the unit of the native projection of the data. See opengeospatial/ogcapi-features#654 (comment)

• selection of properties

• US #143

• #146

In GitLab by @benoitdm-oslandia on Aug 29, 2022, 09:44

In GitLab by @benoitdm-oslandia on Sep 19, 2022, 09:13

"Feature" defines additional features on GET: [schema for update/replace](http://docs.ogc.org /DRAFTS/20-002.html#feature-representations)

• pbm of container modification by other applications ==> pbm of cache

• #5

• #6

In GitLab by @benoitdm-oslandia on Sep 19, 2022, 16:41

In GitLab by @benoitdm-oslandia on Sep 19, 2022, 09:16

• modifier les fichiers markdown dans /
• modifier la doc dans /hugo/

voir https://git.oslandia.net/Client-projects/geoplateforme-ign-pg-featureserv/-/blob/develop/internal/data/catalog_db.go#L783 et https://git.oslandia.net/Client-projects/geoplateforme-ign-pg-featureserv/-/blob/develop/internal/data/catalog_db.go#L791

• vérifier que l'api contienne le PUT
• vérifier que le schéma json est disponible
• vérifier que la donnée est modifiée

As editor, I want to completely replace an existing feature in order to modify the collection

In GitLab by @benoitdm-oslandia on Sep 19, 2022, 09:13

• écrire les tests groupés

As admin, I want to identify the sender of the requests in order to be able to validate the access to the resources.

OR

As a data producer, I want the partners to whom I have given the rights to be able to modify/delete/add data in my database in order to keep my collaborative database up to date.

As admin, I want to identify the sender of the requests in order to be able to validate the authentication

Tâches

• vérifier que l'api contienne le PATCH

• vérifier que le schéma json est disponible ?

• vérifier que la donnée est modifiée

• ajouter la route avec nouvelle methode (handler) :
  http PATCH /collections/{collId}/items/{featureId}

• ajouter un nouveau Content-Type :
  application/merge-patch+json

• construire le body (mock):

      {                                                                   
         "geometry": {                                                    
            "coordinates": [                                              
              [[[-122.2679,37.8009],[-122.2679,37.8009],                  
                [-122.2681,37.8007],[-122.2678,37.8005],                  
                [-122.2676,37.8008],[-122.2679,37.8009]]]                 
            ]                                                             
         },                                                               
         "properties": {                                                  
            "apnid": 1310,                                                
            "primary_material": "red brick"                               
         }                                                                
      }

• tests à faire dans le handler :

  • existance {collectionId}
  • existance {featureId}
  • validité du schema (properties et type de geom)

• construire la reponse en json (Content-Type: application/geo+json):

                                                                                                         
      {                                                                   
        "type": "Feature",                                                
        "id": "OB.2",                                                     
        "geometry": {                                                     
          "type": "MultiPolygon",                                         
          "coordinates": [                                                
            [[[-122.2679,37.8009],[-122.2679,37.8009],                    
              [-122.2681,37.8007],[-122.2678,37.8005],                    
              [-122.2676,37.8008],[-122.2679,37.8009]]]                   
          ]                                                               
        },                                                                
        "properties": {                                                   
          "shape_len": 402.19805753,                                      
          "shape_area": 10117.0666708,                                    
          "bldgid3": "258 11TH ST_bldg1",                                 
          "bldgid2": "258 11TH ST",                                       
          "bldgtype": "Store Building",                                   
          "final_apn": "002 006901000",                                   
          "apnid": 1310                                                   
          "nostory": 1,                                                   
          "bldgnum": "bldg1",                                             
          "numbldgs": 1,                                                  
          "comname": "John Sardell & Sons"                                
          "primary_material": "red brick"                                 
        }                                                                 
      }    

• mettre en place les mocks si nécessaire

• ajouter l'impl. openapi pour le swagger

• tester avec le swagger ou curl

• implémenter fonctions d'update UpdateTableFeature dans les catalogues:

  • catalogDB::UpdateTableFeature
  • CatalogMock::UpdateTableFeature

Questions

Gestion d'un tag pour les CRS (autre que l'EPSG:4326 par defaut) ?

Peut on ajouter directement une nouvelle propertie (ex. primary_material) ?
R: non

L'ajout d'une nouvelle properties doit elle être gerée dans l'impl. route pour modification de schema ?
R: Pour l'instant ce n'est pas prévu

• mise en place du mock
• vérifier que l'api contienne le POST
• vérifier que le schéma json est disponible
• vérifier que la donnée est accessible

• gérer les schemas
• gérer le cas d'instance multiple (plusieurs instance de pg_featureserv peuvent elles récupérer les notify de pg)
• gérer les tables à inclure/exclure
• table trigger ou event trigger ?
• quid des droits ? Only superusers can create event triggers. (https://www.postgresql.org/docs/current/sql-createeventtrigger.html)
• remonter la creation destruction des triggers/function sql dans la creation du catalog_db
• refaire un test (goroutine dans catalog_db)

• modifier les fichiers markdown dans /
• modifier la doc dans /hugo/

Comment détecter les changements fait par une application tierce ?

• https://gist.github.com/goliatone/5fbeb1912e5937e8e3cf94618be9bebf
• https://stackoverflow.com/questions/5412474/using-pg-notify-in-postgresql-trigger-function

As editor, I want to partially modify an existing feature in order to update the collection

See "Update" provides the ability to use the HTTP PATCH method to modify parts of an existing resource without having to transmit a complete replacement resource.

Could be tricky to handle if we accept to add new properties to existing feature. By the way, does it mean all the feature will have this new property? And, in this case, what should be the default value? ==> opengeospatial/ogcapi-features#737

As editor, I want to read data in another crs so as not to have to do the conversions on my desktop

Actuellement seuls les types int et string sont testés.

Idées :

SELECT pg_xact_commit_timestamp(xmin), * FROM YOUR_TABLE_NAME where ID=VALUE;

func getWeakETag (table, id) []byte {
    return cache[table][id] 
}

Tests:

• écrire un test GET mock sans condition pour vérifier l'etag
• écrire un test GET DB sans condition pour vérifier l'etag
• écrire un test GET mock avec une condition If-None-Match sur l'etag
• écrire un test GET DB avec une condition If-None-Match sur l'etag
• dans les tests, vérifier que l'etag est bien le même après deux GET
• écrire un test vérifiant les etags WEAK et STRONG pour une même feature/représentation différente
  ----> test TestWeakEtagFromDifferentRepresentationsDb à activer/décommenter dés qu'un autre format que le JSON sera implémenté (GML, HTML ou autre) -> https://git.oslandia.net/Client-projects/geoplateforme-ign-pg-featureserv/-/issues/70
• faire un jeu de tests à part pour les etags

Cache:

• renommer les fonctions du cache pour qu'elles reflètent le type d'etag weak ou strong qu'elles concernent
• ajouter des paramètres à la fonction AddWeakEtag pour la rendre générique (à préciser)
• intégrer les échanges d'etag via l'API sous forme encodée en Base64
• intégrer la valeur du weak etag dans la structure GeoJSON des features
• rédiger la fonction récupérant le weakETag en base si feature déjà présente
• déplacer le cache des etags pour qu'il soit instancié par le catalogue
• ajouter le last modified dans la réponse aux GET sur une feature -> https://git.oslandia.net/Client-projects/geoplateforme-ign-pg-featureserv/-/issues/71

Headers:

• implémenter le traitement du header If-None-Match sur le GET
• implémenter le traitement du header If-None-Match sur les autres méthodes CRUD (PUT/PATCH/?) -> https://git.oslandia.net/Client-projects/geoplateforme-ign-pg-featureserv/-/issues/72
• implémenter le traitement du header If-Match et mettre à jour la documentation swagger -> https://git.oslandia.net/Client-projects/geoplateforme-ign-pg-featureserv/-/issues/73
• mettre à jour la documentation swagger pour If-None-Match

Divers:

• ajouter une API REST pour décomposer un strong en weak -> https://git.oslandia.net/Client-projects/geoplateforme-ign-pg-featureserv/-/issues/74
• intégrer le couple schema + table pour les requêtes en base -> https://git.oslandia.net/Client-projects/geoplateforme-ign-pg-featureserv/-/issues/75

As editor, I want to create a feature in an existing collection in order to enrich the collection

• vérifier que l'api contienne le DELETE
• vérifier que la donnée est supprimée

Partiellement réalisé via #19

func etag(tableName string, id, query_param, crs) string {
     // crc := crc32.ChecksumIEEE(data) # weak 
     weakETag := getWeakETag (tableName, id)
     return fmt.Sprintf(`W/"%s-%s-%d-'Reference to deleted milestone 08'X"`, name, crs, len(data), weakETag)
}

table_name + crs + base64 (id, champ, weak)

• écrire un test GET intégrant la récupération du strongETag dans les mocks
• écrire un test GET intégrant la récupération du strongETag
• écrire un test GET avec If-Match pour comparaison strongETag
• écrire un test PUT avec If-Match pour comparaison strongETag
• écrire un test PATCH avec If-Match pour comparaison strongETag
• rédiger la fonction getStrongETag

As editor, I want to add or modify data in another crs so as not to have to do the conversions on my post

"Feature" defines additional features on GET: crs

What about the current crs stored and those that are broadcast?

• #18
• #17

As editor, I want to have GML data schemas in order to know the fields needed to update the collection

Idées :

SELECT pg_xact_commit_timestamp(xmin), * FROM YOUR_TABLE_NAME where ID=VALUE;

func getWeakETag (table, id) []byte {
    return cache[table][id] 
}

• écrire un test GET sans condition pour vérifier le weakETag extrait du StrongETag
• écrire un test GET avec une condition If-None-Match sur le weak eTag
• rédiger la fonction getWeakETag avec mock
• rédiger la fonction générant le weakETag en base si nouvelle feature
• rédiger la fonction récupérant le weakETag en base si feature déjà présente

• modifier les fichiers markdown dans /
• modifier la doc dans /hugo/

Le fichier go.sum n'est peut être pas nécessaire et dans ce cas autant le supprimer afin d'éviter de commiter chaque modification de paquet (qui peut dépendre de la version de go)

Voir aussi : https://stackoverflow.com/questions/53837919/should-go-sum-file-be-checked-in-to-the-git-repository

Pour les benchmark et tests de charge

• pérennisation des résultats reflexion pour garder et comparer les rapports (==> CI ?)
• pousser les benchmarks pour la validation du cache / etags

voir : https://git.oslandia.net/Client-projects/geoplateforme-ign-pg-featureserv/-/blob/develop/internal/data/catalog_db.go#L544

As editor, I want to save my modifications on the latest version of the data in order to have an integrated collection and obtain the latest version efficiently

• #72
• #81
• #82
• #73
• #74
• #142
• #77
• #43
• #51
• #75

"Create/Replace/Delete" provides the ability to add, replace, and delete individual resources from 'a collection

• #3
• #8
• #9
• #7