Berechnetes Attribut von Suche ausschließen?

[Matthias KÖPER]

Hallo,
ich habe ein berechnetes Attribut erstellt, das mir jetzt erhebliche Probleme bei der Suche macht (das Wiki hatte mich gewarnt…). Wenn ich in der Listenansicht meines Objekts suche, dauert es eine halbe Stunde, bis Suchergebnisse angezeigt werden. Gibt es eine Möglichkeit, dieses Attribut von der Suche auszuschließen?

Leider fällt mir auch keine Möglichkeit ein, wie ich das berechnete Attribut ersetzen kann.

Danke,
SKoeper

[Frank Pavlic]

Hallo,
„in der Listenansicht meines Objekts suche“ heisst das kleine Suchfeld oberhalb der Ergebnisliste ?
Egal wie, setze die Zeile
log4j.logger.SQLLogger=DEBUG in die conf/log4j.properties. Dann wird die SQL protokolliert. Damit kannst Du dann mit den Datenbank-tools die SQL auf Performance analysieren, z.B. explain in postgresql.

Gruß
Frank

[Matthias KÖPER]

Hallo,
ja, ich meine das kleine Feld oben. Ich hatte das Statement schon protokolliert, auch mit Explain mir die Laufzeit angesehen. Ich habe die Abfrage im pg-Admin ausgeführt und einmal die Abfrage des berechneten Attributs herausgenommen. Der Unterschied ist gravierend. Es liegt also definitiv an dem berechneten Feld. Die Tabelle des Businesobjekts hat im Moment 43000 Zeilen, tendenz steigend und 43000 Mal das Feld berechnen ist wohl zu viel des Guten. Ich versuche gerade einen Workaround mit einer Jobregel, dann wird das Feld zwar mit Verzögerung befüllt, aber das ist immer noch besser, als ohne Suche zu leben.

SKoeper

[Papa Schlumpf]

Warum berechnest du das Attribut nicht einfach beim Speichern der Dinge von denen es abhängt neu? Dann gäbe es keine Verzögerung und die Suche funktioniert.

[Matthias KÖPER]

… weil das Attribut nichts mit Speichern sondern mit Drucken zu tun hat und dafür gibt es noch keinen Einstiegspunkt für eine Regel. Dies ist erst für Version 4.5 angekündigt.
Ich habe jetzt eine Jobregel dafür geschrieben. Das berechnete Attribut war zwar schöner, aber so funktioniert es wenigstens.

[Papa Schlumpf]

Ok, dann geht das natürlich nicht.

Was ich in diesem Fall schon gemacht habe, ist das Dokument nicht über den Druckbutton, sondern in einer Regel zu drucken (und dann in einem Dateifeld zu hinterlegen). Vielleicht ist das in diesem Fall eine Option. Aber wenn es so funktioniert ist ja in Ordnung.

[Matthias KÖPER]

Geht leider auch nicht, die Leute drucken aus der Listenansicht…

[Frank Pavlic]

Hi,
kannst Du mal eine Performance-Killer-SQL posten oder in einer Datei hochladen? Wenn Du willst, schaue ich Sie mir an…

Gruß
Frank

[Ramin Goettlich]

Es sollte eigentlich keinerlei Performance-Implikationen geben, wenn man das fraglich Feld schlicht und einfach aus der Suchergebnisliste ausblendet…

Es werden nur die Felder geladen (bzw. berechnet), die auch dargestellt werden.

[Matthias KÖPER]

@nuclosian:
Danke für den Tipp, ich hatte schon den Verdacht, dass nur die sichtbaren Felder durchsucht werden, nachdem ich das SQL-Statement gesehen habe. Das Feld müssen die Leute aber im Blick haben, darum kann ich es nicht ausblenden. Ich habe das Problem jetzt mit einer Jobregel gelöst, die mein Feld mit etwas Verspätung setzt, das reicht.

@f.pavlic:
Es ging darum, die Dokumente zu kennzeichnen, die bereits gedruckt wurden. Ich habe das über den Umweg der automatisch beim Drucken angehängten Dokumente gemacht. Diese zähle ich einfach. Ich bin kein Datenbank-Performance-Profi, aber erstmal sieht die Funktion in meine Augen harmlos aus. Was ich nicht weiß ist, ob der Kostenfaktor 100 richtig gewählt ist und ob ein falscher Wert dazu führt, das der Ausführungsplan der Abfrage schlecht gewählt wird.

Das Problem entsteht, wenn man in der Listenansicht sucht. Das SQL-Statement, das Nuclos für die Suche erzeugt, führt dazu, dass die Funktion für alle 43 000 Zeilen Datensätze ausführt. Damit ist die Datenbank dann doch überfordert…

CREATE OR REPLACE FUNCTION nuclos.JAE5_ANZDOCUMENT(id numeric)
RETURNS numeric AS
$BODY$
DECLARE
menge numeric;
BEGIN
SELECT COUNT(intid_t_ud_genericobject) INTO menge
FROM nuclos.t_ud_go_document
WHERE strcomment = ‚Automatisch angefügtes Dokument‘
AND intid_t_ud_genericobject = id
GROUP BY intid_t_ud_genericobject; RETURN menge;
END;
$BODY$
LANGUAGE plpgsql VOLATILE
COST 100;

[color=#008800]An dieser Stelle möchte ich mich einmal ganz herzlich bei euch beiden für alle Antworten, Mühen und Geduld bedanken. Ohne euch wäre ich lange nicht so weit mit Nuclos gekommen!
Leider kann ich virtuell keine Schokolade zu euch rüberbeamen.[/color]

SKoeper

[Frank Pavlic]

Hallo,
das ich das richtig verstehe: du zählst die Dokumente, die zu einem bestimmten Datensatz gehören, und gibst die Anzahl der vorhandenen Dokumente zurück. Wenn dem so ist,dann versuche es mit folgender SQL:


SELECT (COUNT(intid) OVER (partition by intid_t_ud_genericobject)) INTO menge
FROM nuclos.t_ud_go_document
WHERE strcomment = 'Automatisch angefügtes Dokument'
AND intid_t_ud_genericobject = id;


Gruß
Frank

[Autor]

Beiträge