Home Forum Allgemeines Allgemeines zu Nuclos Berechnetes Attribut von Suche ausschließen?

Ansicht von 11 Beiträgen - 1 bis 11 (von insgesamt 11)
  • Autor
    Beiträge
  • #8401
    Matthias KÖPER
    Teilnehmer

    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

    #8402
    Frank Pavlic
    Teilnehmer

    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

    #8403
    Matthias KÖPER
    Teilnehmer

    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

    #8404
    Papa Schlumpf
    Teilnehmer

    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.

    #8405
    Matthias KÖPER
    Teilnehmer

    … 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.

    #8406
    Papa Schlumpf
    Teilnehmer

    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.

    #8407
    Matthias KÖPER
    Teilnehmer

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

    #8410
    Frank Pavlic
    Teilnehmer

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

    Gruß
    Frank

    #8411
    Ramin Goettlich
    Teilnehmer

    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.

    #8413
    Matthias KÖPER
    Teilnehmer

    @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

    #8415
    Frank Pavlic
    Teilnehmer

    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

Ansicht von 11 Beiträgen - 1 bis 11 (von insgesamt 11)