http://django-haystack.readthedocs.io/en/v2.5.0/backend_support.html#unsupported -backends-alternatives a mon premier brouillon résumant ma position sur les nouveaux backends, qui est essentiellement que nous n'avons pas assez de bénévoles le temps de soutenir quoi que ce soit d'autre, mais serait heureux de créer des projets sous l'organisation django-haystack pour quiconque souhaite travailler sur un.

Pour les modifications apportées aux backends existants (par exemple, la prise en charge d'AWS ElasticSearch), nous devrions voir combien de changements cela impliquerait dans le code existant et à quel point il serait difficile de le tester.

Les nouveaux backends devraient-ils être dans le code principal ?
Pourraient-ils être des bibliothèques supplémentaires facultatives que les gens installent au besoin ?

NB. Je suis très pro d'avoir un backend AWS, mais je peux comprendre du point de vue des bénévoles que c'est difficile.

@LegoStormtroopr Dans le passé, je pense qu'il y avait une tendance à les inclure dans le noyau à la fois parce que Django le fait pour les bases de données et parce que la gestion des packages Python et l'hébergement du code source étaient plus difficiles (rappelez-vous que Haystack remonte à environ 2007). Le projet principal de Django a beaucoup plus de contributeurs et d'infrastructure de support que nous n'avons pas et puisque l'empaquetage Python est tellement plus facile qu'il ne l'était, je pense qu'il est logique de créer chacun comme un projet séparé qui peut être installé indépendamment et peut extraire automatiquement toutes les bibliothèques facultatives (par exemple, si vous installez django-haystack , nous ne voulons pas extraire les bibliothèques de support pour les backends dont vous n'avez pas besoin, mais un nom de package plus spécifique comme xapian-haystack , django-haystack-solrcloud , django-haystack-aws-elasticsearch , etc. pourraient dépendre en toute sécurité de toutes les bibliothèques nécessaires).

Le principal avantage de ceci est qu'il simplifie les cycles de développement, de test et de publication - par exemple, si vous vouliez créer ce package django-haystack-aws-elasticsearch , vous pouvez envoyer des mises à jour à chaque fois que les bibliothèques ES changent sans avoir à tester Solr, Whoosh, etc. .

J'étais clairement d'accord avec ce design. Il aura besoin d'une bonne API pour brancher le backend

Les salutations! Je suis le créateur des derniers PR d'Elasticsearch, #1460 et #1461, et j'ai lancé un package séparé comprenant toutes les versions - plus un travail de refactorisation indispensable et la résolution des erreurs ES5.x restantes.

https://github.com/CraveFood/django-haystack-elasticsearch

Disponible en django-haystack-elasticsearch sur PyPI.
Toute aide à la révision du code, à la détection de bogues ou à de nouvelles fonctionnalités serait très appréciée.

En ce qui concerne la connexion à AWS ES, j'ai pu le faire sans aucun sous-classement en utilisant requests-aws4auth .
Cela implique un peu de code dans settings.py , mais pas trop.

ELASTICSEARCH_URL = 'https://asdfasdfasdffakefake.us-east-1.es.amazonaws.com/'
USE_AWS_ELASTICSEARCH = 'es.amazonaws.com' in ELASTICSEARCH_URL
elasticsearch_kwargs = {}

if USE_AWS_ELASTICSEARCH:
    import elasticsearch
    from requests_aws4auth import AWS4Auth

    awsauth = AWS4Auth(AWS_ES_ACCESS_KEY_ID, AWS_ES_SECRET_ACCESS_KEY, AWS_REGION, 'es')
    elasticsearch_kwargs.update(
        http_auth=awsauth,
        connection_class=elasticsearch.RequestsHttpConnection,
    )

HAYSTACK_CONNECTIONS = {
    'default': {
        'ENGINE': 'haystack.backends.elasticsearch2_backend.Elasticsearch2SearchEngine',
        'URL': ELASTICSEARCH_URL,
        'INDEX_NAME': 'haystack',
        'KWARGS': elasticsearch_kwargs
    },
}

Compte tenu de la popularité d'AWS, cela semble être quelque chose que nous pourrions vouloir avoir dans la documentation ou, si vous avez le temps pour une demande d'extraction, peut-être quelque chose qui pourrait être automatiquement supprimé de l'URL.

Je serais heureux de tenter ma chance - une chose que l'extrait ci-dessus n'aborde pas est les rôles IAM automatisés. Si les informations d'identification changent, la classe est instanciée avec les informations d'identification d'accès d'origine, mais après environ 30 secondes, elle n'aura plus l'autorisation d'accéder à l'instance ES.

Voici un aperçu qui montre ce que nous faisons :
https://gist.github.com/LegoStormtroopr/4a9a2110eb03c661894529b508d83845