Fix Mailfilter

[JohannMaierhofer]

Ich habe einige Bugs in meinem Filter bei den Mails gefunden.

• Mit dem JOIN werden Mails vervielfacht wenn sie mehrere Mailempfänger haben. Für jeden Empfänger entsteht ein Eintrag. Ich habe jetzt das JOIN so verschoben, dass es nur beim Filtern nach einem Empfänger gemacht wird. Da dann der Empfänger gefiltert wird, wird auch in diesem Fall nichts mehr vervielfacht.
• Bei Mail Empfänger hatte ich auf das Attribut betreff verglichen (copy paste Fehler). Korrekter Weise vergleiche ich jetzt den Namen und Vorname.
• Die Vergleiche nach bis Datum hatten nicht richtig funktioniert. Es wurden die Mails mit dem bis Datum nicht angezeigt obwohl "<=" benutzt wurde. Das liegt hier wohl daran, dass die Mails mit Uhrzeit gespeichert werden und das bis Datum wohl die Uhrzeit 0Uhr hat. Damit sind alle Mails des gesetzten Tages später. Ich addiere jetzt einen Tag auf das bis Datum. Damit ist das Limit am Ende des Tages.

[lenilsas]

Den Fehler hatte ich auch schon bemerkt. So ist es schon wesentlich besser, allerdings werden die Mails immer noch mehrfach aufgelistet, wenn der Namensfilter auf mehrere Empfänger einer Mail passt. Hier müsste z.B. ein DISTINCT mit rein, wie man das einbauen kann weiß ich allerdings nicht.

[JohannMaierhofer]

Den Fehler hatte ich auch schon bemerkt. So ist es schon wesentlich besser, allerdings werden die Mails immer noch mehrfach aufgelistet, wenn der Namensfilter auf mehrere Empfänger einer Mail passt. Hier müsste z.B. ein DISTINCT mit rein, wie man das einbauen kann weiß ich allerdings nicht.

Ich hatte erst eine Implementierung mit einem direkten DB Query in #235 implementiert und da das DISTINCT verwendet. Bei einem anderen Feature #233 wo ich das so gemacht hatte bekam ich den Kommentar, dass diese direkten Queries ineffizient sind. Ich hatte das dann damals auf die Implementierung auf den DBIterator umgetellt. Bei dieser Implementierung kann man kein DISTINCT setzen.

Es gibt jetzt also nur zwei Möglichkeiten. Entweder ich ändere die Implementierung wieder zurück oder wir lassen das so und akzeptieren die Unschönheit.

[JohannMaierhofer]

Da in diesem View je nach Filter sehr viele Einträge entstehen können würde ich die aktuelle Version bevorzugen, weil sie dann wahrscheinlich performanter ist. Gerade wenn man evtl. über ein Netzwerk remote zugreift. Jetzt gibt es ein einziges Query. Bei der anderen Implementierung würde für jeden gefunden Eintrag ein weiteres Select passieren so wie ich das verstanden habe.

[dippeal]

Da in diesem View je nach Filter sehr viele Einträge entstehen können würde ich die aktuelle Version bevorzugen, weil sie dann wahrscheinlich performanter ist. Gerade wenn man evtl. über ein Netzwerk remote zugreift. Jetzt gibt es ein einziges Query. Bei der anderen Implementierung würde für jeden gefunden Eintrag ein weiteres Select passieren so wie ich das verstanden habe.

Ja erstmal so lassen, testen und Erfahrung sammeln. Wenn die Stimmen über lange Ladezeiten laut werden, dann schauen wir noch mal drüber.

[JohannMaierhofer]

Wenn wir es so lassen, dann ist es ja performant.

Die bessere Lösung wäre sowieso, wenn man das Distinct standard mäßig im DBIterator implementieren könnte.