Django-tastypie: ImportError : impossible d'importer le nom 'QUERY_TERMS' sur Django 2.1

Le message disparaît après avoir remplacé resource.py par ceci :

try:
    from django.db.models.sql.constants import QUERY_TERMS
except ImportError:
    # Django 2.1
   QUERY_TERMS = {
      'exact', 'iexact', 'contains', 'icontains', 'gt', 'gte', 'lt', 'lte', 'in',
      'startswith', 'istartswith', 'endswith', 'iendswith', 'range', 'year',
      'month', 'day', 'week_day', 'hour', 'minute', 'second', 'isnull', 'search',
      'regex', 'iregex',
   }

J'essaierai de créer un PR plus tard

Il faut généralement quelques semaines pour implémenter une compatibilité complète pour une nouvelle version de Django.

Pour ce numéro, QUERY_TERMS a probablement été déplacé ; plutôt que de le réimplémenter, nous devrions trouver la nouvelle bonne façon d'obtenir une liste des termes SQL pris en charge par l'ORM.

On dirait que QUERY_TERMS a été supprimé .

Cela devient un problème assez difficile à résoudre; savoureuxpie s'appuyait fortement sur QUERY_TERMS pour pré-valider rapidement les filtres. Il ne semble pas y avoir de moyen efficace de régénérer cet ensemble d'opérateurs sans réviser ModelResource.build_filters . C'est attendu depuis longtemps, de toute façon; la validation par rapport à une liste constante d'opérateurs rendait impossible l'ajout d'opérateurs supplémentaires sans correction de singe, et la liste globale d'opérateurs signifiait qu'elle autoriserait des opérations absurdes pour des champs qui n'ont aucun sens, comme un filtre insensible à la casse sur un champ entier.

La voie à suivre consiste probablement à refactoriser build_filters pour récupérer le champ Django et utiliser la nouvelle API de recherche pour valider l'opération.

Cela a été corrigé dans #1564 et fusionné dans la branche django-2.1 . Cette branche n'est pas prête à être publiée en raison d'autres échecs de test (voir # 1562), mais j'ai confirmé que les échecs de test restants ne sont pas liés à QUERY_TERMS , ce problème peut donc être clos.

Pour éviter toute confusion supplémentaire, je laisserai ce problème ouvert jusqu'à ce que le reste du support 2.1 soit implémenté et fusionné avec master.

La suite de tests passe maintenant sous Django 2.1. Je publierai sur PyPI le 9/3 si aucun bogue majeur n'est trouvé avant cette date.

Cela supprimera également la prise en charge de Django 1.8, qui était en fin de vie en avril.

Sorti aujourd'hui.

Semble fonctionner correctement, @georgedorn Merci !