Abfangen von leerer warehouse_id bevor Objekt gesucht wird

[kivitendo-erp.git] / SL / DB.pm

diff --git a/SL/DB.pm b/SL/DB.pm
index 2d394f6..f125847 100644 (file)
--- a/SL/DB.pm
+++ b/SL/DB.pm
@@ -4,7 +4,6 @@ use strict;
 
 use Carp;
 use Data::Dumper;
-use SL::DBConnect;
 use English qw(-no_match_vars);
 use Rose::DB;
 use Rose::DBx::Cache::Anywhere;
@@ -14,11 +13,13 @@ use base qw(Rose::DB);
 __PACKAGE__->db_cache_class('Rose::DBx::Cache::Anywhere');
 __PACKAGE__->use_private_registry;
 
-my (%_db_registered, %_initial_sql_executed);
+my (%_db_registered);
 
 sub dbi_connect {
   shift;
 
+  # runtime require to break circular include
+  require SL::DBConnect;
   return SL::DBConnect->connect(@_);
 }
 
@@ -30,34 +31,31 @@ sub create {
 
   my $db = __PACKAGE__->new_or_cached(domain => $domain, type => $type);
 
-  _execute_initial_sql($db);
-
   return $db;
 }
 
-my %_dateformats = ( 'yy-mm-dd'   => 'ISO',
-                     'yyyy-mm-dd' => 'ISO',
-                     'mm/dd/yy'   => 'SQL, US',
-                     'dd/mm/yy'   => 'SQL, EUROPEAN',
-                     'dd.mm.yy'   => 'GERMAN'
-                   );
+sub client {
+  create(undef, 'KIVITENDO');
+}
+
+sub auth {
+  create(undef, 'KIVITENDO_AUTH');
+}
 
 sub _register_db {
   my $domain = shift;
   my $type   = shift;
 
+  require SL::DBConnect;
   my %specific_connect_settings;
   my %common_connect_settings = (
     driver           => 'Pg',
+    european_dates   => ((SL::DBConnect->get_datestyle || '') =~ m/european/i) ? 1 : 0,
     connect_options  => {
-      pg_enable_utf8 => $::locale && $::locale->is_utf8,
+      pg_enable_utf8 => 1,
     },
   );
 
-  if ($::myconfig{dateformat}) {
-    $common_connect_settings{european_dates} = 1 if ($_dateformats{ $::myconfig{dateformat} } || '') =~ m/european/i;
-  }
-
   if (($type eq 'KIVITENDO_AUTH') && $::auth && $::auth->{DB_config} && $::auth->session_tables_present) {
     %specific_connect_settings = (
       database        => $::auth->{DB_config}->{db},
@@ -109,19 +107,6 @@ sub _register_db {
   return ($domain, $type);
 }
 
-sub _execute_initial_sql {
-  my ($db) = @_;
-
-  return if $_initial_sql_executed{$db} || !%::myconfig || !$::myconfig{dateformat};
-
-  $_initial_sql_executed{$db} = 1;
-
-  # Don't rely on dboptions being set properly. Chose them from
-  # dateformat instead.
-  my $pg_dateformat = $_dateformats{ $::myconfig{dateformat} };
-  $db->dbh->do("set DateStyle to '${pg_dateformat}'") if $pg_dateformat;
-}
-
 sub _flatten_settings {
   my %settings  = @_;
   my %flattened = ();
@@ -182,22 +167,53 @@ configuration.
 =item C<with_transaction $code_ref, @args>
 
 Executes C<$code_ref> with parameters C<@args> within a transaction,
-starting one if none is currently active. Example:
+starting one only if none is currently active. Example:
 
   return $self->db->with_transaction(sub {
     # do stuff with $self
   });
 
-One big difference to L<Rose::DB/do_transaction> is the return code
-handling. If a transaction is already active then C<with_transcation>
-simply returns the result of calling C<$code_ref> as-is.
+There are two big differences between C<with_transaction> and
+L<Rose::DB/do_transaction>: the handling of an already-running
+transaction and the handling of return values.
+
+The first difference revolves around when a transaction is started and
+committed/rolled back. Rose's C<do_transaction> will always start one,
+then execute the code reference and commit afterwards (or roll back if
+an exception occurs).
+
+This prevents the caller from combining several pieces of code using
+C<do_transaction> reliably as results committed by an inner
+transaction will be permanent even if the outer transaction is rolled
+back.
+
+Therefore our C<with_transaction> works differently: it will only
+start a transaction if no transaction is currently active on the
+database connection.
+
+The second big difference to L<Rose::DB/do_transaction> is the
+handling of returned values. Basically our C<with_transaction> will
+return the values that the code reference C<$code_ref> returns (or
+C<undef> if the transaction was rolled back). Rose's C<do_transaction>
+on the other hand will only return a value signaling the transaction's
+status.
 
-Otherwise the return value depends on the result of the underlying
-transaction. If the transaction fails then C<undef> is returned in
-scalar context and an empty list in list context. If the transaction
-succeeds then the return value of C<$code_ref> is returned preserving
+In more detail:
+
+=over 2
+
+=item * If a transaction is already active then C<with_transaction>
+will simply return the result of calling C<$code_ref> as-is preserving
 context.
 
+=item * If no transaction is started then C<$code_ref> will be wrapped
+in one. C<with_transaction>'s return value depends on the result of
+that transaction. If the it succeeds then the return value of
+C<$code_ref> will be returned preserving context. Otherwise C<undef>
+will be returned in scalar context and an empty list in list context.
+
+=back
+
 So if you want to differentiate between "transaction failed" and
 "succeeded" then your C<$code_ref> should never return C<undef>
 itself.