Suite à donner aux perfs API V2

[submarcos]

Suite de l'analyse et des premières évolutions indiquées dans #3260.

• Généraliser / remettre à plat l'utilisation des filtres géographiques

  • ?trek=xxx ou ?near_trek=xxx
  • utilisation des liens toplogiques si disponibles (ex: signaletiques), des dwithin (comme actuellement) si pas disponibles (modèles non topologiques et cas NDS)
  • commencer par lister les endpoints géométriques utilsant les topologies
  • inspecter GeotrekNearbyContentFilter pour savoir comment proceder (refacto, remplacer par filterset etc)

• Préparer la table de suivi des modifications (pour permettre de connaitre la derniere date d'ajout / modification / suppression dans le but d'invalider le futur cache des endpoints listes)

  • creer un modele avec OneToOneField content_type et date
  • creer des triggers AFTER INSERT / UPDATE / DELETE pour mettre à jour la date associée au content_type

• Commencer à définir les nouveaux endpoints

  • de la forme /api/v2/trek/xxxx/pois au lieu de /api/v2/pois?trek=xxxx (en utilsant @action(detail=False), et les meme serializer que les viewsets deja existants, e nfactorisant si possible)
  • en utilisation le meme système de cache que les endpoints detail mais en utilisant la derniere date de modif de la liste (pois), de l'objet (trek) et des filtres de l'api pour le calcul de la clé de cache.
  • y aller endpoint par endpoint (d'abord rajouter les objets dépourvus de lien topologique comme Contenus et évènements touristiques, outdoor, puis tous les autres objets)

[babastienne]

Dans la table de suivi des modifications imaginer dans un second le fait d'avoir le nombre d'éléments par modèle (pour gagner du temps par rapport aux requetes count effectuées sur les queryset) ?

[marcantoinedupre]

PR #3500 créée pour le premier point "Généraliser / remettre à plat l'utilisation des filtres géographiques".