Django-haystack: SortableIntField dans Solr 5.0.0 est obsolète

On dirait qu'il ne s'agit que d'une pull request pour modifier les types de champs à deux endroits :

https://github.com/django-haystack/django-haystack/search?utf8=%E2%9C%93&q=SortableIntField

Je crains qu'il ne s'agisse pas seulement de remplacer le nom du champ... Je suis malheureusement un débutant sur les détails d'un schéma Solr. Aussi, d'autres problèmes apparaissent avec la version 5.0.0, comme order_by un champ Date qui semble cassé...

+1
Luttant avec DateField ne pouvant pas être trié...

Raison : impossible de trier sur le champ à plusieurs valeurs : registration_date

@philippeluickx Vous devriez essayer la pull-request #1148 qui fonctionne bien avec 5.0.0

Oui, essayez-le maintenant !

Obtenir une erreur ici...

Traceback (appel le plus récent en dernier) :
Fichier "orava_project/manage.py", ligne 17, dans
execute_from_command_line(sys.argv)
Fichier "/home/orava/.virtualenvs/orava/local/lib/python2.7/site-packages/django/core/management/ init .py", ligne 385, dans execute_from_command_line
utilitaire.execute()
Fichier "/home/orava/.virtualenvs/orava/local/lib/python2.7/site-packages/django/core/management/ init .py", ligne 377, en exécution
self.fetch_command(sous-commande).run_from_argv(self.argv)
Fichier "/home/orava/.virtualenvs/orava/local/lib/python2.7/site-packages/django/core/management/base.py", ligne 288, dans run_from_argv
self.execute (_args, * _options. dict)
Fichier "/home/orava/.virtualenvs/orava/local/lib/python2.7/site-packages/django/core/management/base.py", ligne 338, en exécution
sortie = self.handle(_args, *_options)
Fichier "/home/orava/.virtualenvs/orava/local/lib/python2.7/site-packages/haystack/management/commands/build_solr_schema.py", ligne 56, dans le handle
self.log(champ, resp, backend)
Fichier "/home/orava/.virtualenvs/orava/local/lib/python2.7/site-packages/haystack/management/commands/build_solr_schema.py", ligne 98, dans le journal
raise Exception('impossible de décoder l'API Solr, êtes-vous sûr d'avoir démarré Solr et créé le Core configuré (%s) ?' % backend.conn.url)
Exception : impossible de décoder l'API Solr, êtes-vous sûr d'avoir démarré Solr et créé le Core configuré (http://127.0.0.1:8983/solr/orava_core) ?

Serait-ce à cause du signe # ? Je peux accéder à l'administrateur via :
http://127.0.0.1 :8983/solr/#/orava_core

Il semble que vous n'ayez pas démarré ou configuré votre Solr 5.0.0 Core nommé "orava_core".
L'URL sans # est bonne.
J'ai annulé par inadvertance des modifications dans les documents qui expliquent comment démarrer Solr 5.0.0 et créer un nouveau noyau avant d'exécuter manage.py build_solr_schema (plus d'arguments sauf --settings ici)
Vérifiez la dernière version de la doc : https://github.com/Stupeflix/django-haystack/blob/master/docs/installing_search_engines.rst

J'ai vérifié et revérifié.
Il fonctionne comme il se doit, le noyau existe et le service solr est opérationnel.
Je ne sais pas si c'est une aide, mais la réponse que je reçois.

noyau manquant dans l'URL ? http://127.0.0.1 :8983/solr/schema devrait être http://127.0.0.1 :8983/solr/orava_core/schema ?

 {'cookies' : <[]>, '_content' : '\n\n \n\n\n
Erreur Interne du Serveur
 \n
Le serveur a rencontré une condition inattendue qui l'a empêché de répondre à la demande
 \n
Vous pouvez obtenir les détails techniques ici .
 \nVeuillez continuer votre visite sur notre page d'accueil .\n
 \n\n\n', 'headers' : {'date' : 'Tue, 03 Mar 2015 20:27:59 GMT', 'accept-ranges' : 'bytes', 'content-type' : 'text/ html; charset=UTF-8', 'content-length' : '486'}, 'url' : u'http://127.0.0.1:8983/solr/schema', 'status_code' : 500, '_content_consumed' : True , 'encodage' : 'UTF-8', 'requête' :, 'lien':, 'elapsed' : datetime.timedelta(0, 0, 32916), 'raw' :, 'raison' : 'Erreur du serveur', 'historique' : []}

Pourriez-vous essayer d'écrire un nouveau test sur la commande build_solr_schema sans arguments (= compatible 5.0.0) dans la suite de tests ? Cela m'aiderait à résoudre le problème, cela aiderait également à fusionner la demande d'extraction ... merci

Le fait est que j'essaie toujours de le faire fonctionner ... En fournissant l'option --stdout, j'ai généré le schéma XML, mais même avec cela, le DateField est multivalué (ce qui n'est pas le cas)

Je n'aurais également aucune idée de la façon d'écrire un test pour la génération de schéma, car Solr 5 est totalement nouveau pour moi (et j'envisage sérieusement de rétrograder juste pour que cela fonctionne). désolé!

Un autre ne fonctionne pas comme prévu : [Raison : le paramètre de tri n'a pas pu être analysé en tant que requête et n'est pas un champ existant dans l'index : geodist()]

Avoir le sentiment que la botte de foin n'est pas encore prête pour la version 5.0.0 et a besoin de quelques tests supplémentaires avant de passer en production. Je donnerai volontiers le soutien que je peux, mais en déclassant pour l'instant...

Cela s'attendait à ce qu'avec Solr 5, si vous copiez un schema.xml dans le répertoire principal, il sera écrasé par la définition de schéma géré par défaut.

"managed-schema" est généré automatiquement par Solr 5 à la création du noyau et vous ne devez pas le modifier, mais mieux utiliser l'API REST Schema. C'est pourquoi j'ai écrit le nouveau build_solr_schema.

en savoir plus : https://cwiki.apache.org/confluence/display/solr/Managed+Schema+Definition+in+SolrConfig

Bien sûr, plus de tests, c'est mieux, mais je pense que nous pouvons travailler un peu plus sur la pull request #1148 et le faire !

La raison pour laquelle votre DateField est toujours multivaluée est qu'une ancienne configuration de schéma est toujours prise en compte par le schéma géré de votre noyau. Vous devriez peut-être recommencer : supprimez le noyau, supprimez le répertoire principal, créez le noyau et à nouveau build_solr_schema.

puis vérifiez votre Schema dans l'admin web de votre core où vous avez la configuration réelle prise en compte par Solr. Schema.xml n'est pas pris en compte par Solr 5 par défaut

Via le navigateur de schéma, le DateField est marqué comme multivalué pour les propriétés et le schéma, mais pas pour l'index (aucune idée de ce que cela signifie).

J'ai simplement créé un deuxième noyau et j'ai les mêmes problèmes.

Solr est opérationnel
1 nœuds Solr trouvés :

Processus Solr 14332 exécuté sur le port 8983
{
"solr_home":"/var/solr/data/",
"version":"5.0.0 1659987 - anshumgupta - 2015-02-15 12:26:10",
"startTime":"2015-03-04T07:40:49.99Z",
"uptime": "0 jours, 4 heures, 7 minutes, 38 secondes",
"memory":"87 Mo (%17,7) sur 490,7 Mo"}

Veuillez essayer cette application django et son "manage.py solr" pour tester le déploiement de solr 5.0.0
https://github.com/Stupeflix/django-haystack-solr-commands

Avant tout, veuillez arrêter toute autre instance Solr pour éviter les conflits.
Tout sur l'installation et la configuration est dans le README.md
C'est ce que je travaille personnellement maintenant.
J'espère que cela fonctionnera maintenant... car je ne comprends pas plus que cela votre problème.

Nous devrions déplacer cette discussion vers pull-request https://github.com/django-haystack/django-haystack/issues/1148

La plupart des problèmes de Solr 5+ peuvent être résolus en utilisant un modèle schema.xml personnalisé basé sur l'un des schémas par défaut de Solr 5 https://github.com/nazariyg/Solr-5-for-django-haystack

Les étapes données par @nazariyg sont très utiles, merci.

Dans mon cas (django-haystack 2.4.0 et Sol 5.3.0), j'ai construit le schéma (commande build_solr_schema) avec le modèle par défaut et édité la sortie avant de coller dans le répertoire conf :
-remplacer sort.Sortable<type>Field cours par sort.Trie<type>Field
-supprimer l'argument enablePositionIncrements="true" dans les filtres avec la classe solr.StopFilterFactory
-supprimer l'argument side="front" dans le filtre avec solr.EdgeNGramFilterFactory

Ces classes et arguments Solr sont dépréciés dans les versions précédentes.

@asier5 Vous auriez probablement encore besoin d'avoir les types de champs edge_ngram et ngram django-haystack définis dans le schéma si jamais vous décidez d'ajouter une fonctionnalité d'auto-complétion.

@nazariyg Merci pour l'information. Je vois que la sortie de build_solr_schema définit déjà ces deux types de champs.