Django-haystack: Die Verwendung von solr als Backend schlägt bei der ersten Suche fehl

Die Abfrage, die ich mache, ist übrigens diese:

results = SearchQuerySet().filter(content=Clean(value)).models(Product)

Ich habe festgestellt, dass solr die generierte Datei schema.xml nicht verwendet. Jetzt beschwert sich Solr darüber:

test_shard1_replica1: org.apache.solr.common.Solr Exception:org.apache.solr.common.SolrException : Conf für Core konnte nicht geladen werden test_shard1_replica1: Plugin-Init-Fehler für [schema.xml] fieldType "sint": Fehler beim Laden der Klasse 'solr .SortierbaresIntField'. Die Schemadatei ist /configs/test/schema.xml

Ich habe das gleiche Problem auch. Ich hatte mich gefragt, ob sich die schema.xml im richtigen Verzeichnis befindet, obwohl ich mir nicht sicher war, wo ich sie sonst platzieren sollte. Ich hatte es unter 'server/solr/core_name_here/conf/' abgelegt und sah, dass das Protokoll mir sagte, dass es eine unerwartete schema.xml gab und dass ich sie entfernen sollte, da sie bereits verwaltet wurde oder ähnliches.

Ok, ich versuche seit Tagen, dieses Problem zu lösen, bin endlich auf den Grund gegangen. Siehe hier: http://stackoverflow.com/questions/30427643/fields-in-apache-solr-response-are-multivalued-when-they-should-be-singular/30484017#30484017

Haystack scheint nicht mit Solr v5.* kompatibel zu sein. Sobald Sie die obigen Anweisungen befolgen, um dieses Problem zu beheben, werden Sie auf ein Problem mit veralteten Klassen und Klassen stoßen, die vollständig aus Solr entfernt wurden, z. B. https://lucene.apache.org/solr/4_2_0/solr-core/ org/apache/solr/schema/SortableIntField.html.

Ich habe dies noch nicht versucht, aber ich würde vorschlagen, möglicherweise auf Solr v4.* oder vielleicht sogar auf v.3.5 gemäß den Dokumenten zurückzusetzen. Jemand sollte die Dokumentation aktualisieren, um dies widerzuspiegeln, und weitere Tests durchführen.

Wenn Sie mit Solr vertraut sind, können Sie alternativ versuchen, die schema.xml zu ändern, aber ich weiß nicht, ob Sie später auf andere Probleme stoßen werden.

Zugehöriges Ticket:
https://github.com/django-haystack/django-haystack/issues/1199

4.x wird definitiv unterstützt – alle Tests laufen gegen 4.7. @sampeka danke, dass

Schau dir meinen Kommentar zu #1183 an. Ich bin mir nicht sicher, ob Sie auf der ganzen Linie auf Probleme stoßen, aber ich habe einfach eine der standardmäßigen schema.xml verwendet und in die entsprechenden Django-Felder eingefügt, damit die Indizierung auf Solr 5.1 funktioniert. Sie müssen Felder nach Bedarf für Ihre spezifischen Modelle hinzufügen, aber das hat mich auf den Weg gebracht. Ich bin noch nicht so weit in der Django-App , aber diese hat rich_content_extraction, um zumindest Inhalte in meinen Index zu bekommen.

@nikolaz111 Ich habe ein paar Schritte herausgefunden, um diesen Fehler VORÜBERGEHEND zu beheben:

• in solrconfig.xml ändern Sie die Standardschemafactory in die Klasse ClassicIndexSchemaFactory
• für Klasse initParams:

<initParams path="/update/**,/query,/select,/tvrh,/elevate,/spell,/browse">
    <lst name="defaults">
      <str name="df">_text_</str>
    </lst>
  </initParams>

ändern

<initParams path="/update/**,/query,/select,/tvrh,/elevate,/spell">
            <lst name="defaults">
            <str name="df">text</str>
            </lst>
</initParams>

• starte mange.py rebuild_index
• Da wir schema.xml in den Kern überschreiben, vermeiden Sie die Verwendung von ManagedIndexSchemaFactory, viele Klassen in solrconfig.xml werden nicht aufgerufen. Es gibt eine XML, die ich jetzt verwende, ich hoffe, es würde jemand interessieren
  https://gist.github.com/DrChai/033604cd04c869f40ade

Hat jemand Solr 5 dazu gebracht, mit Haystack zu arbeiten?

Mir fällt ein Fehler nach dem anderen ein. Derzeit bei Error instantiating class: 'org.apache.lucene.analysis.core.StopFilterFactory' für den Feldtyp text_general hängen geblieben.

Ich habe es derzeit in Betrieb. Meine größte Empfehlung für den Anfang ist, die standardmäßige Solr-Schema.xml zu verwenden und einfach die erforderlichen Django-Felder hinzuzufügen. Sie müssen id, django_ct, *_exact (ich habe es gerade als dynamisches Feld eingefügt) und vielleicht ein paar andere hinzufügen. Ich denke, es wird Ihnen viel Zeit sparen, anstatt andersherum zu gehen.

Ich habe aufgegeben und bin einfach bei dem "dynamischen" Schema geblieben, das Solr standardmäßig zu verwenden scheint.

Das scheint bei mir funktioniert zu haben https://github.com/nazariyg/Solr-5-for-django-haystack

Sieht positiv aus, werde ich ausprobieren und berichten.

Die Problemumgehung von @nazariyg funktioniert für mich. Was für Kopfschmerzen.

@nazariyg Welche Haystack & Django-Version verwenden Sie für Ihre Problemumgehung?
Ich bin auf Django 1.9.4 und habe Haystack 2.5 heruntergeladen, um Solr 5.5 unter Win zu versuchen
Vor Ihrem Workaround konnte ich keinen einzigen Treffer von Solr abrufen, jetzt stehe ich immer noch vor dem Problem

_'list'-Objekt hat kein Attribut 'split'_

geworfen von solr_backend.py in diesem Punkt

  for raw_result in raw_results.docs:
            app_label, model_name = raw_result[DJANGO_CT].split('.') 

Bei der Integration mit SOLR6 musste ich zusätzliche Konfigurationen vornehmen. Ich habe die Schritte, die ich befolgt habe, im folgenden Link dokumentiert.

https://github.com/dekanayake/haystack_solr6

Wird es eine Lösung für das Problem geben? Kein Workaround.
Ich habe versucht, für alles die neuesten Versionen zu verwenden.

@dekanayake mach bitte einen pr.

Wird Haystack also jemals mit Solr 6 kompatibel sein?

@cauanicatro es ist schon eine Weile her. #1504 hat einige Updates für die Schema-Generierung abgeschlossen, aber ich betreibe es schon eine ganze Weile

Ich bin auch auf diesen Fehler gestoßen. so frustrierend

@wagaman Gibt es diesen Fehler immer noch?

@wagaman hast du einen reproduzierbaren testfall?

Danke für die Antworten. Ich habe slor 6. Ich habe eine Datenbank, in der ich rohes HTML sammle, sodass jede Zeile ziemlich groß ist. Wenn ich den Index neu generiere, sagt er "content", meine HTML-Zelle, ist zu groß. Ich habe online einem Tutorial gefolgt, um den Typ von strings in text_general zu ändern.

pysolr.SolrError: Solr responded with an error (HTTP 400): [Reason: Exception writing document id piaoyouquan.piaoyou.1003 to the index; possible analysis error: Document contains at least one immense term in field="content" (whose UTF8 encoding is longer than the max length 32766), all of which were skipped. Please correct the analyzer to not produce such terms. The prefix of the first immense term is: '[60, 100, 105, 118, 32, 99, 108, 97, 115, 115, 61, 34, 114, 105, 99, 104, 95, 109, 101, 100, 105, 97, 95, 97, 114, 101, 97, 95, 112, 114]...', original message: bytes can be at most 32766 in length; got 86946. Perhaps the document has an indexed string field (solr.StrField) which is too large]

Dann kann ich den Index generieren. Wenn ich jedoch versuche zu suchen, bekomme ich "'Listenobjekt hat kein Attribut 'Split'". Ich werde die Codes unten posten.

verwaltet-schema.txt
schema.txt
solrconfig.txt

Attributfehler bei /search/
'list'-Objekt hat kein Attribut 'split'
Anfragemethode: GET
Anforderungs-URL: http://127.0.0.1 :8000/search/?q=w
Django-Version: 1.10
Ausnahmetyp: AttributeError
Ausnahmewert:
'list'-Objekt hat kein Attribut 'split'
Ort der Ausnahme: /Users/ja/3.5/lib/python3.5/site-packages/haystack/backends/solr_backend.py in _process_results, Zeile 406
Ausführbare Python-Datei: /Users/ja/3.5/bin/python
Python-Version: 3.5.1
Python-Pfad:
['/Users/ja/Dropbox/Programming/Django/piaoyou',
'/Users/ja/3.5/lib/python35.zip',
'/Benutzer/ja/3.5/lib/python3.5',
'/Users/ja/3.5/lib/python3.5/plat-darwin',
'/Users/ja/3.5/lib/python3.5/lib-dynload',
'/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5',
'/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/plat-darwin',
'/Users/ja/3.5/lib/python3.5/site-packages',
'/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages']
Serverzeit: Mo, 26. Juni 2017 05:01:18 +0000

Umfeld:

Anfragemethode: GET
Anforderungs-URL: http://127.0.0.1 :8000/search/?q=w

Django-Version: 1.10
Python-Version: 3.5.1
Installierte Anwendungen:
['dal',
'dal_select2',
'benutzerdefinierte_Vorlage',
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'piaoyouquan',
'rest_framework',
'Bild nach unten',
'crispy_forms',
'taggit',
'taggit_templatetags2',
'Heuhaufen',
'rauschen',
'next_prev',
'django_extensions']
Installierte Middleware:
['django.middleware.security.SecurityMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.common.CommonMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.middleware.clickjacking.XFrameOptionsMiddleware']

Zurück verfolgen:

Datei "/Users/ja/3.5/lib/python3.5/site-packages/django/core/paginator.py" in count

1. Rückgabe self.object_list.count()

Datei "/Users/ja/3.5/lib/python3.5/site-packages/haystack/query.py" in count

1. zurück len(selbst)

Datei "/Users/ja/3.5/lib/python3.5/site-packages/haystack/query.py" in __len__

1. self._result_count = self.query.get_count()

Datei "/Users/ja/3.5/lib/python3.5/site-packages/haystack/backends/__init__.py" in get_count

1. self.run()

Datei "/Users/ja/3.5/lib/python3.5/site-packages/haystack/backends/solr_backend.py" in run

1. Ergebnisse = self.backend.search(final_query, **search_kwargs)

Datei "/Users/ja/3.5/lib/python3.5/site-packages/haystack/backends/__init__.py" im Wrapper

1. return func(obj, query_string, args, * kwargs)

Datei "/Users/ja/3.5/lib/python3.5/site-packages/haystack/backends/solr_backend.py" in der Suche

1. distance_point=kwargs.get('distance_point'))

Datei "/Users/ja/3.5/lib/python3.5/site-packages/haystack/backends/solr_backend.py" in _process_results

1. app_label, model_name = raw_result[DJANGO_CT].split('.')

Bei der Behandlung der obigen Ausnahme ('list'-Objekt hat kein Attribut 'split') ist eine weitere Ausnahme aufgetreten:

Datei "/Users/ja/3.5/lib/python3.5/site-packages/django/core/handlers/exception.py" in inner

1. Antwort = get_response(Anfrage)

Datei "/Users/ja/3.5/lib/python3.5/site-packages/django/core/handlers/base.py" in _get_response

1. Antwort = self.process_exception_by_middleware(e, Anfrage)

Datei "/Users/ja/3.5/lib/python3.5/site-packages/django/core/handlers/base.py" in _get_response

1. Antwort = Wrapped_callback(request, callback_args, * callback_kwargs)

Datei "/Users/ja/3.5/lib/python3.5/site-packages/django/views/generic/base.py" in view

1. return self.dispatch(request, args, * kwargs)

Datei "/Users/ja/3.5/lib/python3.5/site-packages/django/views/generic/base.py" im Versand

1. Return-Handler(request, args, * kwargs)

Datei "/Users/ja/3.5/lib/python3.5/site-packages/haystack/generic_views.py" in get

1. return self.form_valid(form)

Datei "/Users/ja/3.5/lib/python3.5/site-packages/haystack/generic_views.py" in form_valid

1. 'object_list': self.queryset

Datei "/Users/ja/Dropbox/Programming/Django/piaoyou/piaoyouquan/views.py" in get_context_data

1. context = super(BillSearchView, self).get_context_data( args, * kwargs)

Datei "/Users/ja/3.5/lib/python3.5/site-packages/django/views/generic/list.py" in get_context_data

1. paginator, page, queryset, is_paginated = self.paginate_queryset(queryset, page_size)

Datei "/Users/ja/3.5/lib/python3.5/site-packages/django/views/generic/list.py" in paginate_queryset

1. page = paginator.page(page_number)

Datei "/Users/ja/3.5/lib/python3.5/site-packages/django/core/paginator.py" in Seite

1. Zahl = self.validate_number(Zahl)

Datei "/Users/ja/3.5/lib/python3.5/site-packages/django/core/paginator.py" in valid_number

1. wenn Zahl > self.num_pages:

Datei "/Users/ja/3.5/lib/python3.5/site-packages/django/utils/functional.py" in __get__

1. res = Instanz.__dict__[self.name] = self.func(Instanz)

Datei "/Users/ja/3.5/lib/python3.5/site-packages/django/core/paginator.py" in num_pages

1. if self.count == 0 und nicht self.allow_empty_first_page:

Datei "/Users/ja/3.5/lib/python3.5/site-packages/django/utils/functional.py" in __get__

1. res = Instanz.__dict__[self.name] = self.func(Instanz)

Datei "/Users/ja/3.5/lib/python3.5/site-packages/django/core/paginator.py" in count

1. Rückgabe von len(self.object_list)

Datei "/Users/ja/3.5/lib/python3.5/site-packages/haystack/query.py" in __len__

1. self._result_count = self.query.get_count()

Datei "/Users/ja/3.5/lib/python3.5/site-packages/haystack/backends/__init__.py" in get_count

1. self.run()

Datei "/Users/ja/3.5/lib/python3.5/site-packages/haystack/backends/solr_backend.py" in Run

1. Ergebnisse = self.backend.search(final_query, **search_kwargs)

Datei "/Users/ja/3.5/lib/python3.5/site-packages/haystack/backends/__init__.py" im Wrapper

1. return func(obj, query_string, args, * kwargs)

Datei "/Users/ja/3.5/lib/python3.5/site-packages/haystack/backends/solr_backend.py" in der Suche

1. distance_point=kwargs.get('distance_point'))

Datei "/Users/ja/3.5/lib/python3.5/site-packages/haystack/backends/solr_backend.py" in _process_results

1. app_label, model_name = raw_result[DJANGO_CT].split('.')

Ausnahmetyp: AttributeError bei /search/
Ausnahmewert: 'list'-Objekt hat kein Attribut 'split'

Früher habe ich Whoosh mit Haystack verwendet, es hat mit dem gleichen Code in Django gut funktioniert.

Appium-Python-Client==0.24
schönesuppe4==4.4.1
Zykler==0.10.0
Django==1.10
django-autocomplete-light==3.2.7
django-classy-tags==0.8.0
django-crispy-forms==1.6.1
django-Erweiterungen==1.7.9
django-filter==1.0.4
django-heuhaufen==2.6.1
django-next-prev==1.0.1
django-pagedown==0,1.3
django-taggit==0.22.1
django-taggit-templatetags2==1.6.1
django-uuslug==1.1.8
djangorestframework==3.6.3
dnspython==1.15.0
EasyProcess==0.2.3
ez-Setup==0,9
fake-useragent==0.1.7
gevent==1.2.2
grün==0.4.12
Heuhaufen==0.36
jieba==0.38
lxml==3.6.0
Abschlag==2.6.8
matplotlib==2.0.0
numpy==1.11.0
olefile==0.44
Kissen==4.1.0
pydotplus==2.0.2
pyparsing==2.1.10
pytesseract==0.1.7
python-dateutil==2.6.0
python-slugify==1.2.4
pytz==2016.10
PyVirtualDisplay==0.2.1
regex==2016.4.25
Anfragen==2.9.1
scikit-lernen==0.18.1
scipy==0.19.0
Selen==3.4.3
sechs==1.10.0
sklearn==0.0
tesseract==0,1.3
tqdm==4.14.0
Unidecode==0.4.20
aktualisieren==0.4.4
Werkzeug==0.12.2
Whoosh==2.7.4
winappdbg==1.5
xvfbwrapper==0.2.9

Nach 3-4 Tagen erreichte ich die Lösung.

Lösung 1-: Änderung im Schema

Schritt 1: Gehen Sie zu Ihrer verwalteten Schemadatei für die Sammlung und bearbeiten Sie
Schritt 2: Suchen und ersetzen Sie <field name="django_ct" type="text_general"/> durch <field name="django_ct" type="string"/>

• Betriebssystemversion: Ubuntu 14.04 LTS
• Suchmaschinenversion: Solr 7.2.1
• Python-Version: 3.4.3
• Django-Version: 2.0
• Heuhaufen-Version: 2.8.0

Lösung 2: Kerndatei hacken

Schritt 1: sudo vim /home/your path/site-packages/haystack/backends/solr_backend.py
Schritt 2: Suchen und ersetzen Sie app_label, model_name = raw_result[DJANGO_CT].split('.') durch app_label, model_name = raw_result[DJANGO_CT][0].split('.')

@acdha was ist damit?

Kann jemand, der dieses Problem reproduzieren kann, herausfinden, was seine Schemakonfiguration von der Standardeinstellung ändert? Haystack soll string gemäß https://github.com/django-haystack/django-haystack/blob/9eb42dac5cd918c991ac7c939d6de81a02a1aba1/haystack/templates/search_configuration/schema.xml#L81 verwenden, aber es klingt wie mehrere Personen haben festgestellt, dass sie stattdessen zu text_general werden.

@ krmritunjay11 kannst du es testen?

Ich hatte ein ähnliches Problem und habe die zweite Lösung ausprobiert, die @ krmritunjay11 oben gepostet hat, aber es hat immer noch nicht funktioniert. Derselbe Code und dieselbe Umgebung funktionierten mit Whoosh.

Meine aktuelle Umgebung ist:
Requirements.txt , und ich verwende Solr 7.3.1 (aber ich habe Solr 6.X ausprobiert und die gleichen Fehler erhalten)

Ich bekam folgenden Fehler:

File "<yourpath>/site-packages/django/db/models/fields/__init__.py", line 947, in get_prep_value
TypeError: int() argument must be a string, a bytes-like object or a number, not 'list'

Ich habe Zeile 947 in der obigen Datei geändert von

 return int(value)

zu

 if isinstance(value, list):
     return int(value[0])
 return int(value)

Dies führte zu einem weiteren Fehler:

File "<your path>/site-packages/haystack/query.py", line 181, in post_process_results
    result.pk = result_klass(result.pk)
TypeError: int() argument must be a string, a bytes-like object or a number, not 'list'

Was ich behoben habe, indem ich die Zeile 181 von geändert habe

 result.pk = result_klass(result.pk)

zu

 if isinstance(result.pk, list):
    result.pk = result_klass(result.pk[0])
 else:
   result.pk = result_klass(result.pk)

Die Suche funktioniert jetzt, aber meine Lösung scheint hackig und nicht robust zu sein.

Haben Sie eine Idee, warum dies passieren könnte und ob es eine bessere Lösung gibt?

Ich habe eine andere Lösung gefunden, ohne die Kerndateien von django zu berühren.

In/site-packages/haystack/query.py, ändern Sie Zeile 181 von:

result.pk = result_klass(result.pk)

Zu:

result.pk = result_klass(result.pk[0])

Und fügen Sie vor Zeile 205 Folgendes hinzu:

pks = [pk[0] for pk in pks]

Der try-Block endet also so:

207         try:
208             ui = connections[self.query._using].get_unified_index()
209             index = ui.get_index(model)
210             objects = index.read_queryset(using=self.query._using)
211             pks = [pk[0] for pk in pks]
212             return objects.in_bulk(pks)

Das funktionierte mit django 1.11, haystack 2.7.0 und solr 5.5.5

Hi.

Ich habe das gleiche Problem und habe Lösungen von anderen Kommentatoren kombiniert, um eine funktionierende Lösung zu finden. Das Gute daran ist, dass Sie SolrEngine überschreiben und Ihre feste Version verwenden können, bis sie im Heuhaufen behoben ist.

Ich verwende haystack 2.8.1 und solr 8.5.2.

Bearbeiten Sie die Datei haystack/backends/solr_backend.py, um zu überprüfen, ob sie für Sie funktioniert:

• Suchen und Ersetzen
  python app_label, model_name = raw_result[DJANGO_CT].split('.')
  zu
  python app_label, model_name = raw_result[DJANGO_CT][0].split('.')
• Suchen und Ersetzen
  python result = result_class(app_label, model_name, raw_result[DJANGO_ID], raw_result['score'], **additional_fields)
  zu
  python result = result_class(app_label, model_name, raw_result[DJANGO_ID][0], raw_result['score'], **additional_fields)
• Suchen und Ersetzen
  python for key, value in raw_result.items(): value = value[0]
  zu
  python for key, value in raw_result.items(): if isinstance(value, list): value = value[0]

Jede PR ist willkommen.

Jede PR ist willkommen.

Ja, aber ich fühle mich nicht kompetent genug, um eine vollständig praktikable Lösung vorzuschlagen. Meine Änderungen funktionieren für mich einwandfrei, aber ich habe nicht auf der niedrigeren Version der Solr-Engine getestet. Lohnt es sich noch eine PR zu erstellen?

Reproduzierbar mit django-haystack 3.0 und Solr 7.7.3

@jcrbsa Können Sie einen nicht bestandenen Test einreichen? Ich habe keine Möglichkeit das zu reproduzieren.

@acdha , folge diesen Schritten

Zeigen Sie nach der Abfrage per Formular den folgenden Fehler in solr_backend.py an:
C:\Python37\lib\site-packages\haystack\backends\solr_backend.py, Zeile 525, in _process_results

Zeigen Sie nach der Änderung in solr_backend.py und der neuen Abfrage per Formular den folgenden Fehler an:
C:\Python37\lib\site-packages\django\db\models\fields__init__.py, Zeile 1778, in get_prep_value

Das wird nicht reproduziert, wahrscheinlich weil ich ein Standard-Solr-Schema habe, das den erwarteten Typ verwendet. Können Sie einen nicht bestandenen Test vorlegen?