So schick die Datenbankabfragen per Rose sind, will man doch ab und an schauen, was da im Hintergrund auf Datenbankebene passiert, also welche SQL-Queries eigentlich generiert werden.

Während man beim alten Code in der kivitendo.conf unter [debug] per
global_level = QUERY
noch alle SQL-Abfragen in der Logdatei protokollieren konnte, muß man bei Rose nun
dbix_log4perl = 1
einstellen, um die von Rose generierten Queries zu sehen. Das produziert dort auch immer unheimlich viel Ouput.

In der Console kann man bei Manager-Methoden einen debug-Parameter übergeben, wo das generierte SQL ebenfalls angezeigt wird:
my $invoices = SL::DB::Manager::Invoice->get_all( where => [ id => 962 ], debug => 1);
SELECT
t1.amount,
t1.cp_id,
t1.currency_id,
< ... snip ... >
t1.type
FROM
ar t1
WHERE
t1.id = ? (962)


Man kann aber auch das Logging explizit für alle Anfragen in der console Session (oder sogar beim Entwickeln von Test-Skripts) anstellen:

$Rose::DB::Object::Manager::Debug = 1;
$Rose::DB::Object::Debug = 1;

Ab dann sieht man direkt in der console, welche SQL-Abfragen im Hintergrund passieren, z.B. bei der Benutzung eines Filters:
SL::DB::Manager::Invoice->get_all(where => [ SL::DB::Manager::Invoice->type_filter('invoice') ]);

SELECT
t1.amount,
t1.cp_id,
t1.currency_id,
< … snip … >
t1.type
FROM
ar t1
WHERE
(
(
t1.storno = ? OR
t1.storno IS NULL
) AND
t1.amount >= ? AND
t1.invoice = ?
) (0, 0, 1)

Ein paar Beispiele zum selber Ausprobieren:

Schnell schauen, welche Abfragen mit with_objects oder require_objects generiert werden:

Alle Artikel, mit LEFT OUTER JOIN auf die Tabelle partsgroup
my $parts = SL::DB::Manager::Part->get_all( with_objects => [ 'partsgroup' ] );

Nur die Waren, die eine Warengruppe haben:
my $parts = SL::DB::Manager::Part->get_all( require_objects => [ 'partsgroup' ] );

Oder der Unterschied in der Abfrage, ob man einen Artikel per
my $part = SL::DB::Part->new( id => 962 )->load;
oder per
my $part = SL::DB::Manager::Part->find_by( id => 962 );
ausliest.