Django-haystack: SortableIntField in Solr 5.0.0 ist veraltet

Sieht so aus, als ob dies nur ein Pull-Request ist, um die Feldtypen an zwei Stellen zu ändern:

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

Ich fürchte, dies ist nicht nur eine Frage des Ersetzens des Feldnamens ... Ich bin leider ein Anfänger, was die Details eines Solr-Schemas angeht. Außerdem treten mit Version 5.0.0 andere Probleme auf, wie order_by ein Datumsfeld, das defekt zu sein scheint ...

+1
Probleme damit, dass DateField nicht sortierbar ist ...

Grund: Sortierung nach mehrwertigem Feld nicht möglich: Registration_date

@philippeluickx Sie sollten den Pull-Request #1148 ausprobieren, der mit 5.0.0 gut funktioniert

Ja, probiere es jetzt aus!

Bekomme hier einen Fehler...

Traceback (letzter Anruf zuletzt):
Datei "orava_project/manage.py", Zeile 17, in
execute_from_command_line(sys.argv)
File "/home/orava/.virtualenvs/orava/local/lib/python2.7/site-packages/django/core/management/ init .py", Linie 385, in execute_from_command_line
Dienstprogramm.execute()
File "/home/orava/.virtualenvs/orava/local/lib/python2.7/site-packages/django/core/management/ init .py", Linie 377, in ausführen
self.fetch_command(subcommand).run_from_argv(self.argv)
Datei "/home/orava/.virtualenvs/orava/local/lib/python2.7/site-packages/django/core/management/base.py", Zeile 288, in run_from_argv
self.execute(_args, *_options. dict )
Datei "/home/orava/.virtualenvs/orava/local/lib/python2.7/site-packages/django/core/management/base.py", Zeile 338, in execute
Ausgabe = self.handle(_args, *_options)
Datei "/home/orava/.virtualenvs/orava/local/lib/python2.7/site-packages/haystack/management/commands/build_solr_schema.py", Zeile 56, im Handle
self.log(Feld bzw. Backend)
Datei "/home/orava/.virtualenvs/orava/local/lib/python2.7/site-packages/haystack/management/commands/build_solr_schema.py", Zeile 98, in log
raise Exception('Solr API kann nicht dekodiert werden, sind Sie sicher, dass Sie Solr gestartet und den konfigurierten Core (%s) erstellt haben?' % backend.conn.url)
Ausnahme: Solr API kann nicht dekodiert werden. Sind Sie sicher, dass Sie Solr gestartet und den konfigurierten Core erstellt haben (http://127.0.0.1:8983/solr/orava_core) ?

Könnte es am #-Zeichen liegen? Ich kann auf den Admin zugreifen über:
http://127.0.0.1 :8983/solr/#/orava_core

Es scheint, dass Sie Ihren Solr 5.0.0-Core mit dem Namen "orava_core" nicht gestartet oder konfiguriert haben.
Die URL ohne # ist gut.
Ich habe versehentlich Änderungen in den Dokumenten rückgängig gemacht, die erklären, wie man Solr 5.0.0 startet und einen neuen Kern erstellt, bevor man manage.py build_solr_schema ausführt (keine weiteren Argumente außer --settings dort)
Überprüfen Sie die letzte Version der Dokumente: https://github.com/Stupeflix/django-haystack/blob/master/docs/installing_search_engines.rst

Ich habe es überprüft und doppelt überprüft.
Es läuft wie es sollte, der Kern ist vorhanden und der Solr-Dienst ist aktiv.
Ich bin mir nicht sicher, ob dies eine Hilfe ist, aber die Antwort bekomme ich zurück.

Kern fehlt in der URL? http://127.0.0.1 :8983/solr/schema sollte http://127.0.0.1 :8983/solr/orava_core/schema sein?

 {'Cookies': <[]>, '_content': '\n\n \n\n\n
interner Serverfehler
 \n
Der Server ist auf eine unerwartete Bedingung gestoßen, die ihn daran gehindert hat, die Anfrage zu erfüllen
 \n
Technische Details erhalten Sie hier .
 \nBitte setzen Sie Ihren Besuch auf unserer Homepage fort .\n
 \n\n\n', 'headers': {'date': 'Di, 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 , 'encoding': 'UTF-8', 'request':, 'Verbindung':, 'elapsed': datetime.timedelta(0, 0, 32916), 'raw':, 'Grund': 'Serverfehler', 'Verlauf': []}

Könnten Sie versuchen, einen neuen Test über den Befehl build_solr_schema ohne Argumente (= 5.0.0 kompatibel) in der Testsuite zu schreiben? Dies würde mir helfen, das Problem zu beheben, und dies würde auch dazu beitragen, dass die Pull-Anfrage zusammengeführt wird ... danke

Die Sache ist die, ich versuche immer noch, es zum Laufen zu bringen ... Durch die Bereitstellung der Option --stdout habe ich das XML-Schema generiert, aber selbst damit bekomme ich DateField als mehrwertig (was nicht der Fall ist)

Ich hätte auch keine Ahnung, wie man einen Test für die Schema-Generierung schreibt, da solr 5 für mich völlig neu ist (und ich ernsthaft erwäge, ein Downgrade durchzuführen, nur um es zum Laufen zu bringen).. Entschuldigung!

Ein anderer funktioniert nicht wie erwartet: [Grund: sort param konnte nicht als Abfrage geparst werden und ist kein Feld, das im Index vorhanden ist: geodist()]

Ich habe das Gefühl, dass haystack noch nicht bereit für 5.0.0 ist und noch einige Tests benötigt, bevor es in Produktion geht. Ich werde gerne die Unterstützung geben, die ich kann, aber vorerst downgraden...

Dies erwartete, dass bei Solr 5, wenn Sie eine schema.xml in das Core-Verzeichnis kopieren, diese von der standardmäßigen Managed-Schema-Definition überschrieben wird.

"managed-schema" wird von Solr 5 beim Erstellen des Cores automatisch generiert und Sie müssen es nicht bearbeiten, sondern verwenden Sie besser die Schema-REST-API. Aus diesem Grund habe ich das neue build_solr_schema geschrieben.

Lesen Sie mehr: https://cwiki.apache.org/confluence/display/solr/Managed+Schema+Definition+in+SolrConfig

Sicher, mehr Tests sind besser, aber ich denke, wir können noch ein wenig mehr an Pull-Request Nr. 1148 arbeiten und es erledigen!

Der Grund dafür, dass Ihr DateField immer noch mehrwertig ist, ist, dass einige alte Schemakonfigurationen immer noch vom verwalteten Schema Ihres Kerns berücksichtigt werden. Möglicherweise sollten Sie von vorne beginnen: Löschen Sie den Kern, löschen Sie das Kernverzeichnis, erstellen Sie den Kern und bauen Sie_solr_schema erneut auf.

Überprüfen Sie dann Ihr Schema im Web-Admin Ihres Cores, wo Sie die tatsächliche Konfiguration von Solr berücksichtigen lassen. Schema.xml wird von Solr 5 standardmäßig nicht berücksichtigt

Über den Schemabrowser wird das DateField für Eigenschaften und Schema als mehrwertig markiert, aber nicht für Index (keine Ahnung, was das bedeutet).

Ich habe einfach einen zweiten Kern erstellt und habe die gleichen Probleme.

Solr ist in Betrieb
1 Solr-Knoten gefunden:

Solr-Prozess 14332 läuft auf 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 Tage, 4 Stunden, 7 Minuten, 38 Sekunden",
"memory":"87 MB (%17,7) von 490,7 MB"}

Bitte probieren Sie diese Django-App und ihre "manage.py solr" aus, um die Bereitstellung von solr 5.0.0 zu testen
https://github.com/Stupeflix/django-haystack-solr-commands

Stoppen Sie vor allem
Alles zur Installation und Konfiguration befindet sich in der README.md
Damit arbeite ich jetzt persönlich.
Ich hoffe, es funktioniert jetzt... da ich dein Problem nicht mehr verstehe.

Wir sollten diese Diskussion auf Pull-Request verschieben https://github.com/django-haystack/django-haystack/issues/1148

Die meisten Probleme mit Solr 5+ können durch die Verwendung einer benutzerdefinierten schema.xml-Vorlage basierend auf einem der Standardschemas von Solr 5 gelöst werden https://github.com/nazariyg/Solr-5-for-django-haystack

Die Schritte von @nazariyg sind sehr nützlich, danke.

In meinem Fall (django-haystack 2.4.0 und Sol 5.3.0) habe ich das Schema (build_solr_schema-Befehl) mit der Standardvorlage erstellt und die Ausgabe vor dem Einfügen in das conf-Verzeichnis bearbeitet:
-Ersetze sort.Sortable<type>Field Klassen durch sort.Trie<type>Field
-Entferne das Argument enablePositionIncrements="true" in Filtern mit der Klasse solr.StopFilterFactory
-Entferne side="front" Argument im Filter mit solr.EdgeNGramFilterFactory

Diese Solr-Klassen und -Argumente sind in früheren Versionen veraltet.

@asier5 Sie müssten wahrscheinlich immer noch die Feldtypen edge_ngram und ngram des django-haystack im Schema definiert haben, wenn Sie sich jemals entscheiden, die Funktion zur automatischen Vervollständigung hinzuzufügen.

@nazariyg Danke für die Informationen. Ich sehe, dass die Ausgabe von build_solr_schema diese beiden Feldtypen bereits definiert.