Lösung zu #159 #184
Lösung zu #159 #184
Conversation
|
Dir fehlt wohl der mitgliedskonto.betrag im SQL select:
|
|
@dippeal |
|
Habe den Fix für MySQL gemacht |
|
Eine Implementierung mit weniger requests gegen die DB dafür mit größerem Datensatz ist effizienter bei den meisten Hostern. Der Grund dafür sind Limits wie max_connections. Macht es vielleicht Sinn die Vor-/Namen mit |
|
Ich finde den Vorschlag gut. Dann liefert die Datenbank auch nur die gefundenen Mitgliedskonten und man kann sich den Matchingalgorithmus der im ResultSetExtractor implementiert ist auch sparen. |
|
Warum habe ich es nicht gleich so gemacht wie in dem zweiten Tab. Jetzt passiert auch der Namens Match im SQL. |
|
Ich glaube den ersten Vorschlag #182 können wir verwerfen. |
|
@JohannMaierhofer Vielen Dank für die Implementierung! Wir werden demnächst unsere JVerein-Installation auf Openjverein umstellen und es dann testen. Da wir einen recht großen Verein mit vielen Sonderfällen/komplexer eigener IT haben, sind wir noch nicht dazu gekommen. Da ich ja ein Kopfgeld für den Fix versprochen hatte: Schick mir einfach per Mail dein PayPal oder einen guten Zweck deiner Wahl, du hast dir das Kopfgeld für den Bugfix verdient und er wird unsere Arbeit im Verein bedeutend angenehmer machen ;) |
|
Es gibt jetzt noch eine Sache, die mir aufgefallen ist. Die neue Implementierung über den Namensvergleich mit SQL hat den Nachteil, dass die Umlaute ä, ö etc. nicht in ae, oe etc. umgewandelt werden. Wenn also in der Buchung eine Umlautersetzung durch die Bank etc. stattgefunden hat, dann gibt es evtl. keinen Match. Ich habe mir jetzt gedacht, dass man einen Schalter einzubauen könnte mit dem man die Ersetzung einschalten kann. Dann würde der Code aus dem vorhergehenden Commit durchlaufen. Der sollte auch besser sein als der ursprüngliche Code. Man würde das halt nur einschalten wenn man sieht, dass der Suchname eine Umlautersetzung beinhaltet. Natürlich könnte man aber genau so gut einfach den Suchnamen editieren und die Umlautersetzung korrigieren. Das wäre wohl einfacher. Was meint ihr? Hallo @lukas-mertens, |
Einen Schalter finde ich eine unschöne Lösung. Nachfolgendes muss für name und vorname implementiert werden und das upper muss berücksichtigt werden. oder die where Klausel erweitern um umgewandelte Eingaben/Suchnamen: upper(mitglied.name) like upper() or upper(mitglied.name) like upper() Könnte mir vorstellen, dass die Java-Umwandlung etwas performanter und Fehler unanfälliger ist. |
JohannMaierhofer
force-pushed
the
feature_mk2
branch
from
bb07237
to
5f04959
Compare
|
Das mit dem Replace hat nicht funktioniert. wenn man das im SELECT macht wird zwar für die Ausgabe ersetzt aber nicht im where. Das Replace in das where Statement einbauen hat immer zu einem Syntaxfehler geführt. Aber vielleicht habe ich es ja falsch gemacht. |
Weniger oft die Umlaute umwandeln (reduceWord())
Inzwischen habe ich einiges dazu gelernt und das Problem der alten Implementierung verstanden.
Jetzt gibt es dann in jedem Fall nur ein Query über die Mitgliedskonten. Durch den Filter im Query sollten es aber nicht viel mehr sein als es Mitglieder gibt, eher weniger. Nur wenn man alle gewählt hat wird sehr viel gelesen und erst später auf ein Mitglied gefiltert wenn eines angegeben ist. In diesem Fall werden in Vorschlag 1 weniger Daten geholt aber dort mehr Queries gemacht.
Ich weiß aber nicht was problematischer ist, die Datenmenge die geholt wird oder die Anzahl von Queries die ausgeführt werden.
Ich könnte mir vorstellen, dass diese Implementierung hier noch besser ist als die in #182.
PS: Den Vergleich mit Zweck habe ich auch entfernt und die Länge der Namen auf >2 reduziert.
Ich weiß jetzt nicht wie wir weiter vorgehen. Sollte man zwei Testbuilds machen und es Lukas messen lassen was schneller ist. Oder glauben wir gleich, dass diese hier besser ist, da sie nur ein einziges Query macht?
Endgültig sollte natürlich nur einer der beiden Pull Requests übernommen werden.