[DBIx-Class-Devel] SQL::Statement-based driver support

[Peter Rabbitson]

On Mon, Mar 18, 2013 at 05:14:49PM -0400, Brendan Byrd wrote:
> I currently have topic/SS_DBD_support out there.  It is -mostly- ready.  So
> far, it successfully tests for DBD::CSV and DBD::DBM.  These two tests are
> required for authors and ran for those that have the right modules.  This
> is because it's easy enough to set up a test environment on-the-fly a la
> SQLite, and because these are the best supported.  (DBM comes with DBI, and
> HMB maintains CSV regularly.)
> 
> Yes, SQL::Statement has its own set of idiosyncrasies and limitations.
>  But, we can still support what it is capable of right now, and "caveat
> persona" for anything else.  DBIC will either throw exceptions saying that
> S:S doesn't support this or that, or S:S will error on its own.
> 
> The branch is safe to run and test.  I'll add in the other DBD tests and
> push as I complete testing of them.

Just superficial review, will look at things in detail a tad later this week:

- Please get the thing green on travis for starters

- We need to generate t/lib/test_deploy/DBICTest-Schema... - augment 
  maint/gen_schema (and the corresponding call in 
  maint/Makefile.PL.inc/56_autogen_testddl.pl)

- s/Storage::DBI::SQL::Statement/DBI::DBDFile/ - seems like the more logical
  base class (while the SQLMaker is fine as-is)

- Move the "no-bind-limit" copy into SQLMaker::SQLStatement - make it a
  substituting wrapper around the original

- The txn_begin caller-guessing thing is a no-go. txn_begin needs to remain
  a noop with a carp_once "this driver can not support transactions 
  proceeding at your own risk" and a hard exception on a txn_rollback 
  "Unable to rollback - your data is likely inconsistent"

- The svp_begin is not necessary - by default a storage is assumed to not
  support savepoints. 

- autoinc exception needs to move way earlier before the call, so that one
  does not start inserting NULL's into columns marked is_auto_increment.
  I will do a writeup towards the weekend of all column attrs DBIC currently
  opportunisticaly uses, it will become more apparent then.

- in t/86ss_csv.t you have f_ext => ".csv/r" - is the odd name intentional?


That should do it for now, 2nd round after some of the changes have been 
implemented.