3.9.1 Lieferschein auslagern über Standardlagerplatz wirft Fehler

Question

Moin nochmal,

beim weiteren Testen ist mir noch Folgendes untergekommen:
Beim Versuch, einen Lieferschein über den Standardlagerplatz ohne Prüfung der Lagermenge auszulagern, wird der Fehler

Can't call method "parts_id" on an undefined value at /usr/local/src/lx-office-erp/SL/Controller/DeliveryOrder.pm line 1260.

geworfen. Ich habe den gesamten Workflow über Angebot, Auftragseingang¹, Auftragsbestätigung, Anzahlungsrechnung, Lieferschein verwendet, falls das von Belang ist.

Der Fehler ist in der Steigmann-Werft-Demo reproduzierbar.

Hab dann mal ein wenig nachgeforscht und gefunden, dass ins Array @transfer_requests bereits eine dereferenzierte parts_id gepusht wird. Da ich nicht wusste, wofür das nochmal gut sein kann, habe ich zusätzlich das ganze Item mit dazu gepusht (anstatt einfach die Zeile 1260 entsprechend zu ändern), damit der Vergleich in Zeile 1260 nicht fehlschlägt.

push @transfer_requests, {
  'delivery_order_item'    => $item,
  'delivery_order_item_id' => $item->id,
  'warehouse_id'           => $part->warehouse_id || $default_warehouse_id,

Damit hat das zwar soweit funktioniert, das Auslagern läuft aber dahinter in eine Endlosschleife (ich bekomme einen Timeout-Fehler von mod_fcgi).

Das schaue ich mir dann nach dem Aufstehen nochmal an, vielleicht schaut ja auch mal jemand anders darüber. ;-)

Grüße,

Hannes

Comments

Zwischenstand:

Hab das noch etwas weiter verfolgt, der Timeout tritt offenbar in der Sub save auf, welche in action_transfer_stock aufgerufen wird.

Mit anderen Worten:
Die Sub action_transfer_stock_default läuft mit den beiden kleinen Änderungen durch, am Ende wird von dort die Sub action_transfer_stock aufgerufen, welche bis self->save; kommt, dort tritt dann der Timeout auf.

Schau ich später weiter, muss noch ein wenig arbeiten.

Viele Grüße,

Hannes

---

In der Kaffeepause noch ein wenig weiter geschaut:

In self->save wird die Methode save von SL::Model::Record aufgerufen, und in selbiger komme ich bis

$record->save(cascade => 1);

$record ist ein SL::DB::DeliveryOrder-Objekt, es hängt also nach meinem laienhaften Verständnis beim Zugriff auf die Datenbank.

Die einzige save-Methode, die ich unterhalb SL::DB finde, ist in SL::DB::Object. da steht nach meinem Verständnis nicht viel drin außer einem Pre- und eine Post-Hook und eben dem Save in die DB, das ganze in einer Transaction gekapselt.

Wie man das debuggen könnte, weiß ich nicht, da bin ich zu doof. ;-)

Falls mir hier einer unter die Arme greifen möchte, bitte gern.
Die verwendete Datenbank ist eine Kopie meiner Live-Datenbank, die mit 3.8.0 problemlos funktioniert, wie gesagt mit extensiver Nutzung des Standard-Auslagerns ins Negative.

Für Tipps aller Art bin ich dankbar, es fängt langsam an, Spaß zu machen. :-D

Grüße,

Hannes

---

Ok,

wenn man das dbix-log4perl-Debug anschaltet, sieht man die Endlosschleife halt auch. Kaum macht man es richtig, geht es plötzlich. :-D

Beim Auslagern wird erst

Object.pm:794 Rose::DB::Object::update - prepare(1.216): 'UPDATE delivery_order_items SET ...
Object.pm:818 Rose::DB::Object::update - $execute(1.216) (UPDATE delivery_order_items SET ...
Object.pm:818 Rose::DB::Object::update - affected(1.216): 1
Object.pm:761 Rose::DB::Object::update - $STORE(1) = ['RaiseError',1];
Generic.pm:6080 Rose::DB::Object::MakeMethods::Generic::__check_and_merge - $STORE(1) = ['PrintError',0];
Generic.pm:6081 Rose::DB::Object::MakeMethods::Generic::__check_and_merge - $STORE(1) = ['PrintError',1];
Manager.pm:3217 Rose::DB::Object::Manager::delete_objects - $STORE(1) = ['RaiseError',1];

ausgeführt, was nach meinem Dafürhalten gut aussieht, weil offenbar ein Datensatz betroffen war (affected: 1).
Danach beginnt die Endlosschleife:

Manager.pm:3221 Rose::DB::Object::Manager::delete_objects - prepare(1.217): 'DELETE FROM delivery_order_items_stock WHERE delivery_order_item_id = ?'
Manager.pm:3238 Rose::DB::Object::Manager::delete_objects - execute(1.217) (DELETE FROM delivery_order_items_stock WHERE delivery_order_item_id = ?): 16573
Manager.pm:3238 Rose::DB::Object::Manager::delete_objects - affected(1.217): '0E0'
Manager.pm:3241 Rose::DB::Object::Manager::delete_objects - $STORE(1) = ['RaiseError',1];
Generic.pm:6080 Rose::DB::Object::MakeMethods::Generic::__check_and_merge - $STORE(1) = ['PrintError',0];
Generic.pm:6081 Rose::DB::Object::MakeMethods::Generic::__check_and_merge - $STORE(1) = ['PrintError',1];
Object.pm:757 Rose::DB::Object::update - $STORE(1) = ['RaiseError',1];
Object.pm:761 Rose::DB::Object::update - $STORE(1) = ['RaiseError',1];
Generic.pm:6080 Rose::DB::Object::MakeMethods::Generic::__check_and_merge - $STORE(1) = ['PrintError',0];
Generic.pm:6081 Rose::DB::Object::MakeMethods::Generic::__check_and_merge - $STORE(1) = ['PrintError',1];
Manager.pm:3217 Rose::DB::Object::Manager::delete_objects - $STORE(1) = ['RaiseError',1];

Das wird ca. 40s lang wiederholt, dem Zähler nach zu urteilen ca. 9000x

So, jetzt wirklich schönes WE allerseits. ;-)

/Hannes

EDIT: Timestamps und Severity aus den Logs gelöscht, weil jedenfalls bei mir hier die Scrollbalken nicht erscheinen und man darum das Ende der Zeilen nicht sehen kann.

---

Moin again,

hier an der Stelle stehe ich wirklich erst mal auf dem Schlauch.

$record->save mit dem cascade-Parameter soll - wenn ich die Dokumentation richtig lese - alle verbundenen Datenbankoperationen ebenfalls mit ausführen. An welcher Stelle aus einem UPDATE dann aber ein DELETE wird, und warum die Transaktion in eine Endlosschleife läuft und zurückgerollt wird, erschließt sich mir nicht.

Ich kann das bis vor den Beginn der Transaktion verfolgen, weiter komme ich nicht.
Ob das also eine Endloschleife ist, oder ob mein Datenbestand diese lang andauernde Aktion auslöst, weil irgend etwas "korrigiert" wird, kann ich so nicht nachvollziehen.

Any hints?

Danke und VG,

Hannes