Django-haystack: Unterstützung für ElasticSearch 5.0 hinzufügen

FWIW, ich denke, ElasticSearch 2.X ist immer noch eine wichtige Initiative. Wie bereits erwähnt, hat Elastic 5.0 Breaking Changes und der Upgrade-Pfad sieht etwas holprig aus, daher denke ich, dass die Einführung einige Zeit dauern wird.

ES 5.0 final wurde veröffentlicht.

Was ist mit 2.xx?

@SalahAdDin Ich denke, @mahmoudhossam bezog sich auf die Tatsache, dass ElasticSearch 5.0 über den Release Candidate hinausgeht und jetzt die aktuelle _stable_ offiziell unterstützte ElasticSearch-Version ist.

Es gibt derzeit einige offene Pull Requests #1391 #1336, aber AFAIK gibt es darüber hinaus nichts in Bezug auf die offizielle Haystack-Unterstützung für ES 2.xx

Das Beste, was Sie tun können, ist, zu versuchen, von diesen Zweigen wegzulaufen und zu sehen, ob Sie unterwegs auf Probleme stoßen. Das ist vielleicht der beste Einblick, wie nahe diese Flugzeuge an der Landung sind

Ich denke, dies führt zu einem interessanten Diskussionspunkt über einige grundlegende architektonische Entscheidungen innerhalb von Haystack. Hier ist eine interessante Frage:

Was ist der kleinste gemeinsame Nenner der Funktionalität der Such-Backends jetzt und in der Zukunft?

In den früheren Tagen, wo jedes Backend mehr oder weniger eine einfache Dokumentensuche mit einigen unterschiedlichen Implementierungsansätzen war. Grundlegende Facettierung und Feldunterstützung waren ebenfalls ziemlich verbreitet. Die Entscheidungen in diesem Zusammenhang machten also Sinn.

Jetzt divergiert und spezialisiert sich die Funktionsbreite der Backends jedoch noch mehr. Die beste allgemeine Funktionalität, die ich sehen kann, ist nur eine einfache Dokumentensuche. Und selbst das ist nicht so backend-agnostisch, wie es sich anhört. (Unterschiede in den Analysatorfähigkeiten usw.)

Dies steht im Gegensatz zu RDBMSs mit SQL, die zwar "Standard" sind, aber ziemlich locker sind - die Basismenge an Features und Funktionen, die eine SQL-Schnittstelle unterstützt, ist viel größer und macht so etwas wie ein agnostisches und robustes Backend QuerySet möglich. Beispielsweise haben so unterschiedliche Implementierungen wie SQLite und Redshift einen großen Satz gemeinsamer Funktionen, die mit einer ausreichend gemeinsamen Schnittstelle ausgeführt werden, sodass ein großer Teil der Django-ORM-Funktionen einfach funktioniert.

Angesichts der Tatsache, dass jedes Backend zu divergieren und sich zu spezialisieren scheint, habe ich angefangen, mich zu fragen, ob es sinnvoll sein könnte, die Menge an Funktionen, die mit Ihrem Vanilla SearchQuerySet geliefert werden, zu _reduzieren_?

Dies ist nur ein hypothetisches Extrem - aber stellen Sie sich vor, Vanilla "Core" Haystack hätte nur eine vollständige Dokumentensuche durchgeführt, keine Felder, keine Facetten, keine Statistiken, keine räumliche Suche, nichts weiter .filter(content=) mit einer kleinen Menge von InputType s. Fügen Sie das Signalverarbeitungs-Framework hinzu, um Dokumente auf dem neuesten Stand zu halten, und Sie haben immer noch ein enorm leistungsstarkes Paket, das viel einfacher über Backends hinweg auf dem neuesten Stand gehalten werden sollte.

Dann kommen "contrib"-Pakete herein, um mit mehr Backend-spezifischen spezifischen Merkmalen und Funktionen zu erweitern.

Dies scheint es erheblich einfacher zu machen, den Kern zu warten (der davon profitiert, mit Engines auf dem neuesten Stand zu bleiben) und für diejenigen Spezialisten, die den größeren Satz von Funktionen für jedes Backend verwenden, um die Backend-spezifischen Erweiterungen auf SearchQuerySet zu warten SearchIndex .

Ich weiß, das ist eine etwas radikale Idee. Penny für deine Gedanken @acdha ?

Ich stimme @kcolton zu, Heuhaufen muss modular sein, um an Bodenhaftung zu gewinnen.

Es war schwierig, eine neue Version von haystack herauszubringen, da jedes Backend aktualisiert werden muss, und das ist ein enormer Aufwand für ein einzelnes Softwarepaket.

Das Aufteilen von Heuhaufen in Kern und eine Reihe von Plugins oder Contrib-Paketen würde dem Projekt wirklich helfen.

Dies ist eine lange Diskussion, und ich habe nicht genug Zeit, um ihr gerecht zu werden
gerade jetzt, aber im Allgemeinen stimme ich zu. Das Design von Haystack spiegelt getroffene Entscheidungen wider
über den Zustand der Django- und Python-Paketierung vor fast einem Jahrzehnt und
Es wäre gut, es für eine Veröffentlichung von Haystack 3 erheblich zu überarbeiten. Die
Idee, die in der Vergangenheit aufgekommen ist – ich denke, @honzakral hat es gut gemacht
Vorschlag vor ein paar Jahren – wäre einfach, eine Verlängerung anzunehmen
Punkt, um das Abrufen eines Verbindungshandles für das entsprechende Gerät wirklich zu vereinfachen
Backend-Client, so dass Sie einmal an die Grenzen dessen stoßen, was der Kern SearchQuerySet
können Sie eine saubere Möglichkeit haben, etwas in der Art von was zu tun
Der Raw/Extra-Mechanismus von Django erlaubt es, nur mehr seit der Funktionalität
divergiert weiter. Sogar Kerndinge wie die Suche nach Datensätzen hat
eine ziemlich breite Palette mit Dingen wie den verschiedenen Abfrageparsern von Solr und dem
Mit ElasticSearch können Sie entweder grundlegende Solr-ähnliche Abfragen oder die
reiche JSON-Schnittstelle, die wirklich leistungsfähig ist und daher noch weniger wahrscheinlich ist
portabel abstrahierbar sein.

Ich habe diesbezüglich ein paar Verbesserungen vorgenommen – zB meine Backend-Unterstützung
das Solr-Gruppierungssystem zum Reduzieren/Erweitern (
https://gist.github.com/acdha/0a66ca23984bc8d607936fecd9c29941) erforderlich
weniger Boilerplate als der ältere, den ich gegen Haystack 2.0 in der entwickelt habe
Beta-Ära (https://gist.github.com/acdha/3750774) – aber das glaube ich wirklich
wäre ein guter Bereich für weitere Verbesserungen, also könnten wir das einfach annehmen
Muster, um es leicht zu erkennen, wann Sie über Bord gehen müssen
Portabilität sowieso und gehen Sie aus dem Weg.

Ein erster Schritt, den ich machen möchte, ist, einen Betreuer für jeden Major zu identifizieren
Backend und entweder vollständig in separate Apps umgestalten
(django-haystack-core, -solr, -es, -es2, -whoosh usw.) oder zumindest setzen
einige Zeit in die weitere Reduzierung der Zeit, die jemand, der ist
die daran interessiert sind, in einem Backend mitzuarbeiten, müssen über die anderen Bescheid wissen
für Nicht-Kernfunktionen. Ich benutze Solr hauptsächlich und benutze ES beiläufig, aber es wäre so
wirklich schön, wenn wir den größten Teil der Unterstützung für jedes Backend an delegieren könnten
jemand, der die Upstream-Community aktiv verfolgt und dazu in der Lage wäre
Pflegen Sie ein umfangreicheres .contrib-Modul, ohne das Problem übernehmen zu müssen
Aufbau einer portablen Abstraktion.

Chris

Es tut mir leid, aber ich habe nicht die Bandbreite, um das Elasticsearch-Backend für Heuhaufen zu unterstützen. Ich habe vor einiger Zeit beschlossen, stattdessen eine Elasticsearch-spezifische Bibliothek [0] zu erstellen, die diese hoffentlich für viele Anwendungsfälle ersetzen sollte. Es ist nicht so eng in Django integriert, unterstützt aber die gesamte Bandbreite an Optionen, die Elasticsearch zu bieten hat.

Große Teile davon könnten auch von haystack verwendet werden, um einige der Unterschiede zwischen elastischen Versionen zu abstrahieren (z. B. filtered -Abfrage vs. {"bool": {"filter": []}} ) und den gesamten haystack-Code etwas einfacher zu gestalten. Es bietet sogar Hooks für benutzerdefinierte (De-)Serialisierung und andere Extras. Ich würde auch gerne mehr hinzufügen, wenn es das Portieren von Heuhaufen erleichtern würde.

Fühlen Sie sich frei, dort irgendwelche Probleme zu eröffnen oder sich direkt mit mir in Verbindung zu setzen, ich helfe Pythonistas immer gerne bei Elasticsearch-Problemen.

Danke

0 - https://github.com/elastic/elasticsearch-dsl-py

@acdha @HonzaKral Zunächst einmal danke euch beiden!

Ich denke, Haystacks _current modularly_ hat enorm dazu beigetragen, Traktion zu gewinnen. Aber wie @acdha betonte, bewegt sich die Welt der Such-Backends schnell, wobei das Ökosystem vor 3 Jahren ganz anders aussah.

Wir verwenden Elastic seit 0.X für über 3 Jahre und eine Vielzahl von Anwendungsfällen. Wir haben im Grunde jede Kombination von Elastic + Django ausprobiert.

• Mozillas veraltete Elasticutils
• Verwenden Sie einfach elasticsearch-dsl-py und im Wesentlichen das Beispiel von @HonzaKral für die Integration mit Django
• serverseitige Abfragen über elasticsearch-py , elasticsearch-dsl-py , direkte clientseitige Abfragen, die vor JS DSL (dunkle Zeiten) stattfanden

Wo wir gelandet sind, ist eigentlich eine Kombination aus beidem haystack mit ein paar Erweiterungen, die speziell entwickelt wurden, um das schöne Elasticsearch-dsl-py zu nutzen.

Unser Ansatz entspricht weitgehend dem Beispiel des Solr-Gruppierungssystems zum Ein-/Ausblenden, aber zum Hinzufügen von Elastic-spezifischen Funktionen wie verschachtelten Aggregationen, Vorsuchfiltern, die nicht in die Abfragezeichenfolge eingehen, usw. Wie bereits erwähnt, verwenden wir elasticsearch-dsl-py , um die Benutzeroberfläche sauber zu halten.

Anstatt zu versuchen, .facet zu "reparieren", haben wir einfach eine .aggregate Methode erstellt, die entweder Wörterbuchdefinitionen (wenn Sie Schmerz mögen) oder DSL-Objekte und ein .pre_filter auf an nimmt erweiterte Version von ElasticSearchQueryset : https://gist.github.com/kcolton/d143503fd25a694ffce4cd7e178349ae

Was es uns ermöglicht, so einen verrückten Scheiß zu machen und ihn in < 100 ms zurückzugeben

sqs = sqs.aggregate(
    listing_stage=Terms(field='listing_stage', size=10),
    weeks_listed_histogram=Histogram(field='days_listed', interval=7),
    item_experiment_variations=Terms(field='item_experiment_variations', size=100),
    listing_types_exact=Terms(field='listing_types_exact'),
    listing_test_buckets_exact=Terms(field='listing_test_buckets_exact', size=20),
    sold=Terms(field='sold'),

    acquired_at_week_histogram=DateHistogram(field='acquired_at', interval='week', format='yyyy-MM-dd', min_doc_count=0, order={'_key': 'desc'}, aggs=dict(
        listing_stage=Terms(field='listing_stage', size=10),
        sum_sold_amount=Sum(field='sold_amount')
    )),
)

# Efficient filtering that doesn't affect search score

sqs = sqs.pre_filter(
  Term(category_public=True),
  Term(offer_availability=availability),
  Term(offer_image_healthy=True)
)

Abgesehen vom Upgrade auf 2.X und darüber hinaus sind wir definitiv auf einige Herausforderungen gestoßen, die anscheinend auf Komplexitäten zurückzuführen sind, die _andere_ SearchQuerySet Methoden einführen, und auf große Funktionen, die für mehr Erweiterbarkeit oder zusätzliche Einstiegspunkte aufgeschlüsselt werden könnten. Daraus entstand die Idee, dass es vielleicht keine schlechte Sache wäre, wenn die Vanille SearchQuerySet kleiner wird.

Heuhaufen + DSL-Hybrid, für unseren Anwendungsfall optimiert für die geringste Anzahl von Radneuerfindungen. Nur auf DSL umzustellen, bedeutete, sich um Folgendes kümmern zu müssen:

• Django-Objekt „Rehydrierung“ aus den Suchergebnissen (mit effizientem Prefetching)
• Signalverarbeitung (wir verwenden haystack-celery + weitere Erweiterungen für die Unterstützung verwandter Objekte + zufällige Stapelbefehle)
• Eine Schnittstelle, die Django-Entwicklern vertraut ist und sich (sehr effizient mit ein paar weiteren Erweiterungen) in die bestehenden generischen Ansichten von Django einfügt

Wir ( das Material World Team ) sind bestrebt, auf Haystack zu bleiben _und_ in den nächsten Monaten 5.0 zu erreichen, und freuen uns, auf jede erdenkliche Weise einen Beitrag leisten zu können, da wir sowohl Haystack (wiederum @acdha + Contributors) als auch viel zu verdanken haben DSL für Python (wieder @HonzaKral und Crew)

Die Funktionalität für ein privates Projekt mit spezifischen Anwendungsfällen zum Laufen zu bringen, ist eine Sache, würde aber höchstwahrscheinlich mehr Community-Unterstützung benötigen, um den Überblick über ES-spezifische Funktionen zu behalten – insbesondere diejenigen, die aus unseren Anwendungsfällen herausfallen.

Müssen Sie die aktuellen 2.X-Bemühungen nachholen (es scheint, als wären einige davon nahe dran?) und möglicherweise einen Vorschlag für einen "Weg zu 5.0" zusammenstellen und wie es mit und ohne 2.X-Unterstützung aussehen könnte.

Prost,

Ken Colton
CTO Materielle Welt

@kcolton :

Und Sie haben Recht, elasticsearch-py und elasticsearch-dsl-py zu verwenden!

Dieses Projekt ist nun so gut wie tot. Ich weiß nicht, was es wieder zum Leben erwecken könnte (Kickstarter oder irgendeine andere Kampagne), aber heutzutage verwendet fast niemand SOLR oder Whoosh mit Python. Und es gibt niemanden, der das Problem (mangelnde Unterstützung für moderne ElasticSearch) ernst nimmt. Deshalb sterbe friedlich, Heuhaufen. Du hast in der Vergangenheit gute Arbeit geleistet, aber du bist irrelevant geworden.

Für Interessierte habe ich die aktuelle Elasticsearch Engine auf 2.X portiert. Ich habe es noch nicht geschafft, es mit 5.x zum Laufen zu bringen.

Sie finden es hier: https://pypi.python.org/pypi/elasticsearch2-haystack

Es sollte für alle Versionen bis 2.4 funktionieren, aber es ist nicht perfekt, da es im Wesentlichen 2.x patcht, um wie 1.x auszusehen.

Soweit ich gehört habe, arbeitet jemand an einem neueren Backend, das hoffentlich für die neuesten Versionen von ES optimiert ist, was meiner Meinung nach nicht der Fall ist. Also werde ich keine PR machen - ich stelle es nur zur Verfügung, bis es einen besseren Ersatz gibt.

Wir haben es bei unserer Arbeit an Django-Oscar getestet und es funktioniert im Moment einwandfrei.

Ich arbeite derzeit am Elasticsearch 5 Backend für Heuhaufen. Meiner Meinung nach wäre es derzeit besser, separate Backends für jede Version zu haben.

@ Alkalit. Ich denke, das ist definitiv der richtige Weg. Wir brauchten nur ein Backend, das 2.x schnell unterstützt.

@Alkalit Einverstanden – Ich denke, die Geschichte der Breaking Changes wird wahrscheinlich weitergehen, und der Versuch, die Abwärtskompatibilität in derselben Codebasis aufrechtzuerhalten, hat die Wartung von Haystack in der Vergangenheit definitiv teuer gemacht.

@acdha Je mehr ich darüber nachgedacht habe - der "kleinste gemeinsame Nenner" zwischen dem, was man als Such-Backend betrachten würde (derzeit über die 4 hinaus), scheint im Grunde nur ... "Suche" zu sein:

Kleinster gemeinsamer Nenner aller „Such-Backends“

• Volltext-Dokumentsuche mit Relevanzbewertung (jedoch nicht unbedingt Boosting).
  
  
  
  • Im Grunde eine Tautologie. Sonst wäre es kein Suchindex. Im Gegensatz zu einem herkömmlichen RDBMS, das keine Volltextsuchfunktion hatte, bedeutete „Suchen“ WHERE foo LIKE '%?%' OR bar LIKE '%?%' OR baz LIKE '%?%'
  
  
• Seitennummerierung

Wo Heuhaufen hineinpasst

Die einfache Verbindung einer skalierbaren, flexiblen und robusten dokumentbasierten Volltextsuche mit Django-Modellen und die Durchführung einer generischen Suche über sie hinweg ist _extrem leistungsfähig_.

Das war für uns der mentale Elevator-Pitch in Bezug auf haystack : Echte Suche nach unserem Django-Projekt in Minuten, das einfach funktioniert und keine Kopfschmerzen bei der Wartung verursacht.

Viele moderne RDBMS haben eine verdammt gute Volltextfeldsuche, aber die Tatsache, dass so viele Projekte immer noch Heuhaufen oder andere Suchlösungen verwenden, zeigt, dass es wichtig ist, modellübergreifend suchen und Dokumente anpassen zu können.

Abgesehen von der Dokumentengenerierung macht Haystack einige Dinge sehr gut, die jeder, der ein Such-Framework erstellt, erfinden müsste:

• Den Index aktuell halten. Ein Suchindex ist im Grunde ein Cache und Sie wissen, dass man über Caching spricht. Das Signalverarbeitungs-Framework, das eine Indizierungsstrategie ermöglicht, die viele Geschäftsanforderungen erfüllt. Für uns und wahrscheinlich viele einfache Webanwendungen ist die Kombination von celery-haystack mit seinen Post-Commit-Hooks + regelmäßiger zufälliger Neuindizierung zur Korrektur von "Drifts" eine Indexierungsstrategie, die schnell und dennoch fehlertolerant ist.

• Eine Django-freundliche, vertraute Schnittstelle zum Abrufen von Daten für Ansichten, die eine effiziente „Rehydrierung“ von Objekten aus Suchergebnissen beinhaltet. (Wir bleiben eigentlich bei normalen Formen und generischen CBVs, anstatt Heuhaufen zu verwenden)

Denken Sie an all die zusätzlichen Backends (Suchplattformen + Suche als Service), die einfach verbunden werden könnten und dennoch den Wert der beiden oben genannten Eigenschaften erhalten.

Unser Anwendungsfall liegt tatsächlich außerhalb der 90 % „brauche nur Dokumentensuche“, da wir die eher esoterischen Funktionen von ElasticSearch _brauchen_, aber im Moment hält Heuhaufen immer noch eine gute Balance und hat uns viele Stunden der Neuerfindung des Rades erspart.

@acdha Dies ist ein extremes, aber interessantes Gedankenexperiment:

Stellen Sie sich vor, wo SearchIndex nur das Rendern eines Dokuments, die Signalverarbeitung, die effiziente und sichere Neuindizierung und Rehydrierung erleichtert. Keine Felder

Wobei die SearchQuerySet Vanilla-Schnittstelle models() , .auto_query() , __len__() , __iter__() , __getitem__() + Modellrehydrierung ist. Kein Filter, kein Ausschluss, keine Facette usw

Im Grunde - ein django-haystack-lite . Normalerweise sind Umschreibungen zum Scheitern verurteilt, aber warum ich denke, dass es eher "haystack-lite" als "haystack 3.0" ist, ist, dass es hauptsächlich _Entfernung_ von Code ist.

Ich weiß, dass das die Dinge wirklich auf die Spitze treibt und nicht praktikabel ist – aber ich habe Mühe, mir einen Weg zu überlegen, etwas zu entwerfen, das mit den scheinbar exponentiellen Veränderungen und der Diversifizierung in der Suchwelt im Allgemeinen Schritt halten kann nicht so extrem.

Insbesondere die Tatsache, dass die meisten Such-Backends nicht mehr nur eine Suche sind. Ein einziges Such-Backend wie ElasticSearch kann für NoSQL OLTP, OLAP, Data Warehousing, Big Data Crunching, Echtzeitkommunikation, eingebettet in ETL-Pipelines und viele andere Anwendungsfälle verwendet werden, die fast nichts mit der Suche zu tun haben. Viele von ihnen würden unweigerlich zu Funktionsanfragen werden, und die derzeitige Grundlage macht eine Erweiterung zur Unterstützung solcher Funktionen schwierig.

Ich kann mir _one_ ElasticSearchBackend eigentlich gar nicht mehr vorstellen, ohne dass es sich selbst in eine Küchenspüle verwandelt. Es gibt genug verschiedene ziemlich exklusive Anwendungsfälle innerhalb dieser einen Plattform, um mehrere Backends zu sein.

Das ist ein harter Problemmann. Nochmal Penny für deine (und alle anderen) Gedanken?

Prost,
Ken

@kcolton Dem stimme ich mehr oder weniger zu. Funktionen sollten von Backend zu Backend verfügbar sein, und wir sollten nicht alles in allen Backends anstreben.

Es wäre meiner Meinung nach auch sinnvoller, einem ORM-Ansatz zu folgen, bei dem jede Engine ein separates Projekt ist, anstatt sie an den Kern oder Heuhaufen zu binden.

Bitte unterstützen Sie es!

Wie ist der aktuelle Stand bezüglich ES5-Support? Scheint, als ob dieses Problem ohne einen Spielplan ruhig geworden ist.

Als Neuling bei Django und der Suche insgesamt war Haystack ein wunderbarer Einstieg. Ich glaube nicht, dass Haystacks Tage gezählt sind. Im Gegensatz. Die Möglichkeit, ein Django-Plugin zu verwenden, das ich lokal verwenden und mit Whoosh, Solr und schließlich Elasticsearch ausprobieren kann, war eine erstaunliche Erfahrung.

Die Suche ist im Allgemeinen ein kleines Add-on, und die Möglichkeit, einfach loszulegen und mit der Möglichkeit, die Suchkette zu skalieren (einfach > zisch > elastische Suche), ist nach meiner (kleinen) Erfahrung der häufigste Anwendungsfall für das Hinzufügen einer Suche . Haystack spielt also meiner Meinung nach wirklich eine große und wichtige Rolle für Django und zukünftige Django-Entwickler in Bezug auf die Suche.

Ich denke also, dass die Unterstützung von ElasticSearch 5 wichtig werden wird, also stimme ich diesem Beitrag zu! Und wenn wir, die Neuankömmlinge, trotzdem dabei helfen können, würde ich das gerne ausprobieren. Zumindest kann ich mit einer positiven Bewertung beginnen. Und ich danke Ihnen allen, dass Sie Haystack zu dem gemacht haben, was es heute ist.

@tuxedojoe :
Es wird in absehbarer Zeit nicht passieren, mit oder ohne Up-Votes. Wenn Sie das neueste Gummiband benötigen, verwenden Sie keinen Heuhaufen. Gehen Sie nicht davon aus, dass die Unterstützung für 5.0 in weniger als zwei Jahren verfügbar sein wird.

@barseghyanartur Welche andere Alternative können wir verwenden?

Wenn Sie daran interessiert sind, tatsächlich zu Haystack beizutragen, testen Sie bitte diesen Zweig und berichten Sie über Ihre Ergebnisse. Ich benutze ES nicht viel und bisher hatten wir nicht viel Glück, Freiwillige zu finden, die uns dabei unterstützen.

@SalahAdDin :

Ich bin sehr zufrieden mit elasticsearch-dsl und django-elasticsearch-dsl.

@barseghyanartur , was ist hier mit Hilfe?

@SalahAdDin :

Zur "Hilfe hier":

• https://github.com/django-haystack/django-haystack/pulls/barseghyanartur
• https://github.com/django-haystack/django-haystack/commits?author=barseghyanartur

Siehe auch mein GitHub-Konto. Ich habe an vielen Open-Source-Projekten mitgewirkt.

Generell zum Thema "Haystack" oder "no-haystack". Ich möchte nur ein Werkzeug, das "funktioniert" und gut funktioniert. Wer verwendet heutzutage SOLR, Whoosh, Xapian? ElasticSearch wird viel breiter eingesetzt.

Die Haystack-API ist sehr begrenzt. Wenn Sie ernsthaft mit ElasticSearch arbeiten wollen, werden Sie gegen Haystack kämpfen, ständig hacken, überschreiben, Unterklassen erstellen usw. Code, den Sie schließlich erhalten, sieht schmutzig aus. Zu Ihrer Information, ich habe Haystack mit ElasticSearch 1.x und 2.x verwendet, ich weiß, wovon ich spreche.

ElasticSearch entwickelt sich sehr schnell. Haystack entwickelt sich extrem langsam. Wollen Sie alle Django-Entwickler, die ihre ersten Schritte mit ElasticSearch machen, in Schwierigkeiten bringen? Denn sie werden Probleme bekommen, wenn sie mit Haystack starten, da der Product Owner ein Jahr später sagen wird, dass er Features von ElasticSearch 5.0 nutzen möchte und Haystack den 2.0-Zweig kaum unterstützt.

Wenn Sie sich für ElasticSearch entschieden haben, sind Sie außerdem wahrscheinlich nicht bereit, zu SOLR, Xapian oder einem anderen Backend zu migrieren, das Haystack unterstützt. Würden Sie von PostgreSQL zu SQLite migrieren?

@barseghyanartur Was ist mit Projekten wie django-oscar , die Haystack für die Unterstützung mehrerer Backends verwenden?

Ich denke, Sie haben Recht, aber in meinem Fall gibt es für django-oscar keine Unterstützung für diese Projekte. Im Fall von Wagtail -Projekten mochten sie dich ein wenig, sie implementierten sein eigenes elasticsearch -Backend und -Ende.

Ist dies die relevante PR für dieses Problem? https://github.com/django-haystack/django-haystack/pull/1461

@jonesnc Ja - Ich glaube, es ist an dem Punkt, an dem die Testsuite bestehen sollte, aber mehr Überprüfung gebrauchen könnte, insbesondere nur für grundlegende Dinge wie Dokumentations- / Einrichtungsanweisungen. Eines der anderen Dinge, die ich tun muss, ist zu sehen, ob Landung Nr. 1504 etwas kaputt gemacht hat.

Ich bin mir nicht sicher, ob dies an anderer Stelle besprochen wurde, aber Elasticsearch 5.x unterstützt den Datentyp string nicht mehr .

So wie es jetzt aussieht, verwendet https://github.com/django-haystack/django-haystack/pull/1461 immer noch field_type = 'string' für indexes.CharField (neben anderen Klassen), was zu WARN führt.

[WARN ][oedimStringFieldMapper$TypeParser] Das Feld [string] ist veraltet, bitte verwenden Sie [text] oder [keyword] statt [text]

Ich kann ein Beispiel für dieses Verhalten erstellen, wenn Sie denken, dass es helfen würde.

Wird an diesem Thema noch gearbeitet?

Was ist noch zu tun und wie kann ich helfen?

@jonesnc field_type = 'string' bricht, wenn Elasticsearch aufgrund anderer Parameter keine automatischen Upgrades durchführen kann, also möchte ich, dass es in der PR angesprochen wird

elasticsearch.exceptions.RequestError ... The [string] type is removed in 5.0 and automatic upgrade failed because parameters [term_vector] are not supported for automatic upgrades. You should now use either a [text] or [keyword] field instead ...

@pmaccamp Und ist dies der aktuellste Fork, der dieses Problem behebt?

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

@jonesnc ja, dieser Fork verwendet immer noch field_type='string'

Beim Abfragen no [query] registered for [filtered] stoße ich auch auf ein anderes Problem, das anscheinend auf Änderungen zurückzuführen ist, wie gefilterte Abfragen mit ES 5 https://stackoverflow.com/questions/40519806/no-query-registered-for erstellt werden

Elasticsearch entwickelt sich sehr schnell und hat viele Funktionen. Es scheint mir, dass es für die ganzen django-haystack nicht einfach sein wird, Elasticsearch bald einzuholen.
Es gibt andere Lösungen für die Verwendung von Elasticsearch in Django, einschließlich Elasticsearch DSL und seiner Derivate, aber ich denke, Heuhaufen bietet immer noch eine schönere SearchQuerySet-Syntax.

Es gibt nur wenige benutzerdefinierte Heuhaufen-Backends für Elasticsearch, die durch Suchen im Internet gefunden werden können, aber ich habe es nicht geschafft, eines zu finden, das aktiv gewartet wird und Elasticsearch 5 unterstützt. Daher habe ich ein separates Projekt erstellt, um die Unterstützung für Elasticsearch 5 und andere Elasticsearch- Besonderheiten von Haystack.

Der Quellcode ist unter https://github.com/tehamalab/django-haystack-es zu finden. Bisher scheint es beim Indizieren, Facetten, Boosten und einigen anderen Dingen zu funktionieren, aber ich habe nicht viel getestet und dokumentiert. Ich hoffe, es wird auf die eine oder andere Weise hilfreich sein.

Ich denke immer noch, dass die ExtremelyBaseSearchQuery und ExtremelyBaseSearchBackend ( Ansatz, auf den letztes Jahr Bezug genommen wurde ) immer noch ein solider Weg nach vorne sind.

• Es hält den Kern von Heuhaufen minimal, gut unterstützt und lässt sich mit Django leichter auf dem Laufenden halten, insbesondere mit DJ 2.0 am Horizont
• Erleichtert die Implementierung neuer Backends, sobald sie herauskommen, und beseitigt einige der Komplexitäten, die die Erweiterung der vorhandenen BaseSearchQuery und BaseSearchBackend erschweren.
• Kann sich für die Explosion neuer Such-Backends und -dienste öffnen

@acdha Ich frage mich , ob Sie einen guten Eindruck von der relativen Nutzung der einzelnen Funktionen hatten. Wäre wirklich interessant, eine Umfrage durchzuführen wie:

• Welche Backends verwenden Sie?
• Verwenden Sie Indexfelder?
• Einfache facettierte Felder?
• Facettierte Felder mit Datum?
• Entfernungsfelder?
• Statistik-Facetten
• Hervorhebung
• Rechtschreibkorrektur
• Mehr wie das
• Ngramme
• Schmale Abfragen
• Signalprozessoren
• Echtzeit-Signalprozessoren
• Sellerie-Signalprozessoren
• Die View-, Form- und Template-Helfer
• Haben Sie Komponenten erweitert oder angepasst? Welcher?

etc

Dass die Basis-Engine-Klasse dies unterstützen muss, scheint einfach unhaltbar:

def build_search_kwargs(self, query_string, sort_by=None, start_offset=0, end_offset=None,
                            fields='', highlight=False, facets=None,
                            date_facets=None, query_facets=None,
                            narrow_queries=None, spelling_query=None,
                            within=None, dwithin=None, distance_point=None,
                            models=None, limit_to_registered_models=None,
                            result_class=None):

Jede Suchmaschine spezialisiert sich auf die eine oder andere Weise, diese Schnittstelle scheint jetzt einfach zu breit zu sein. Sogar innerhalb von Elasticsearch haben Sie möglicherweise ein Backend, das sich sehr um Entfernungen kümmert, oder eines, das verschachtelte Objekte verarbeitet, oder eines, das sich auf Analysen konzentriert.

Ich habe einen Fork als POC für diese Idee und es schien gut zu funktionieren. Es erstellte eine neue Basisklasse (im Geiste habe ich eine Schnittstelle einer Unterklasse eingegrenzt, nur um Konflikte für den POC zu vermeiden) und richtete dann neue Backends und darauf basierende Abfragen ein und brachte es an einen Punkt, an dem alle Tests zu diesem Zeitpunkt erneut liefen .

Ich muss es auf den neuesten Stand bringen, es ist ein Jahr hinterher, aber ich werde eine PR davon als RFC veröffentlichen, um mehr Verstand für die Idee zu bekommen.

Elasticsearch 6.0 ist jetzt verfügbar

@codekiln , Holly Scheiße!

@all , was denkst du über " django-haystack-elasticsearch "? Es ist als Pre-Alpha aufgeführt und wurde (zum Zeitpunkt des Schreibens dieses Artikels) seit letztem Jahr nicht mehr auf PyPy aktualisiert. Wird es erfolgreich mit ES 5 und Vanilla Heuhaufen verwendet oder passt es zu CraveFoods Heuhaufengabel?

@codekiln Mit PyPy meinst du wohl PyPI

/pedantisch

@codekiln , bist du dir da sicher?

@jonesnc du hast recht, ich meine PyPI.
@SalahAdDin was meinst du? sicher, was? Elasticsearch 6.0 ist definitiv draußen

@codekiln , dieses Paket funktioniert mit elasticsearch 6.0 ?

@SalahAdDin frage ich eigentlich. Ich erwäge die Verwendung von Raw Elasticsearch-dsl-py und Elasticsearch-py, wollte aber sehen, ob jemand "django-haystack-elasticsearch" verwendet hat oder verwendet.

@codekiln Wie eng planen Sie, ElasticSearch zu folgen? Wenn Sie keine Portabilität benötigen, würde ich in Betracht ziehen, die nativen Elasticsearch-Pakete zu verwenden, da sie Entwickler dafür bezahlen, an ihnen zu arbeiten. Das Verkaufsargument von Haystack ist die Portabilität, aber das ist auch etwas teuer im Hinblick auf die Zeit, die benötigt wird, um etwas wie ES zu verfolgen, das regelmäßig die Schnittstellen ändert, zumal wir kein großes Interesse der Community an dieser Arbeit hatten.

Ich habe gerade # 1461 neu basiert und zusammengeführt