Proper MSSQL last_insert_id() scoping patch by abraxxa
No tests as it is very hard to simulate the problematic behavior - it would only manifest if:
  1) An INSERT statement is issued from connection A
  2) An INSERT statement is issued from connection B
  3) last_insert_id is called from connection A

Without this patch the last id from the second INSERT will be returned in step 3
Tested with both DBICTEST_MSSQL_ODBC_DSN and DBICTEST_MSSQL_DSN against a MSSQL 2005

auto_savepoint support for Oracle and a note on txn_do for with "AutoCommit => 0"

 * Reworded $rs->current_source_alias POD (thanks to castaway).

 * Implemented $rs->current_source_alias.

not necessary

fixup source registration bugs where schema-specific things were being set on class' result_source_instance objects

by setting conn_?id first, we prevent $storage->dbh from recursing through on_connect_do actions

reverting changes for versioning tests

>result_source_instance->source_name should return undef for any class

failing test for load_namespace

credit where credit is due; namely: ME!

fix the just-added test; pass the Storage object to pure-code on_connect callbacks

 failing test for callback on_connect_do getting storage obejct

Add definitions of relationship and relationship bridge, link to them from the rel docs

Re-ordered method docs to be in a more user-needs-it order.
Fixed some obj/table mentions in docs to be consistently $source.

Added standard arguments/return value to all docced methods.
Upadted some method docs.

make clear that search_like is only really there for Class::DBI users

map blob to PG_BYTEA on DBD::Pg

delete() POD patch from Michael Hendricks (slightly reworded)

 * Added myself to the contributors list.

Todoify cdbi failing tests, waiting for schwern

altered schema->populate so that it is a very thin wrapper on top of resultset->populate and changed resultset_populate so that is accepted both the arrayref of hashes and the arrayref of arrayref style of args.  Documented this, updated the tests a bit to make sure it is all good.

more noise debugging messages if debug is on, minor doc tweaks, changes so that the fake sqlite tests will work and laid the groundwork for replication without dbatabase native replication support.

Some cleanups to the m2m warnings test

Try to fix test on 5.10

somehow i messed up the merge. this fixes it

Merge 'belongs_to_null_col_fix' into 'trunk'

Merge 'belongs_to_null_col_fix' into 'trunk'

r24740@martha (orig r5230):  groditi | 2008-12-09 20:28:10 -0500
fix for bug. all tests seem to pass, we still need a new test and more research

minor typo and style change

rename option to undef_on_null_fk and make it default for belongs_to

Introduce 'any_null_means_no_value' option to eliminate wasteful queries. The option is off by default and must be explicitly turned on. Tests, + docs included

Merge 'trunk' into 'belongs_to_null_col_fix'

r24752@martha (orig r5239):  jnapiorkowski | 2008-12-15 17:02:19 -0500
changes to replication so that if a replicant is offline when we do the initial connection (or if we need to globally reconnect later) the connection does not die.  This is different from when a replicant is available just not listening, or if the replicant is too laggy.  Thanks David Steinbrunner for the patch suggestions.

changes to replication so that if a replicant is offline when we do the initial connection (or if we need to globally reconnect later) the connection does not die.  This is different from when a replicant is available just not listening, or if the replicant is too laggy.  Thanks David Steinbrunner for the patch suggestions.

fix for bug. all tests seem to pass, we still need a new test and more research

Make the many-to-many warning use warnings::register;

Fix pod errors so that some storage subclasses show up in cpan properly

Minor doc patch by Caelum

CDBI-compat tests by Dave Horwoth:

    OK. I've attached a patch to t/cdbi-t/15-accessor.t that does several
    things:

    (1) Fixes the way the arguments are built so the sheep argument is
    correct in the tests.

    (2) Adds explicit tests for the number of sheep so we can be sure which
    database record is actually returned.

    (3) Adds tests for find_or_create() with modified accessor names.

    (4) Fixes the test for search() to report all errors

    I still don't fully understand what's going on in the output below but I
    think they are genuine test failures. I'd appreciate it if somebody else
    could run the tests to make sure the results are not some artefact of my
    test environment. I also attached a copy of the modified test script so
    you don't even have to apply the patch first :)

    I don't know what the DestroyWarning at the end is all about.

Trunk passes tests again - todoify everything multicreate related to branch it out, as the task turned out to be more complex (no indentation to aid future merging)

Extend might_have test with ideas from zby

Failing tests by zby, showing that recursing insert() gets in the way of some exotic insert scenarious - waiting for mst to decide course of action

Silence cdbi tests like everything else

Two failing multicreate tests (the root cause of castaway's problem)

Two more sets of might_have - has_many relationships for extra tests

One more (passing) multicreate test and a bit of cleanup

rip away a horribly wrong create_via_update test (will pass when multicreate is merged)

might_have test for castaway to break

Add new test relationship - a track can have a relates single_cd

Revert castaway's test - mildly bogus

Merge 'resultsetcolumn_custom_columns' into 'trunk'

r5165@vger:  mendel | 2008-11-16 20:11:42 +0100
 * Merged in changes from 'resultsetcolumn_custom_columns' branch,

whops

Added failing create-multi test

 * Rewrote fetching the 'select' and 'as' values from the parent resultset to something that's easier to read for everyone.

 * Fixed a bug: did not create the underlying resultset if neither ->next or ->reset is called before ->first was called.

 * Added ->first and ->reset implementation to ResultSetColumn.
 * A bit of refactoring/cleanup of ResultSetColumn.

we use register_extra_source() now

Document the new from usage

resultset attribute from can now take a scalarref and use it verbatim

result_class goodies by Caelum:
- result_class can now be specified as a search attribute, attaching it to the returned resultset
- the specified class is now autoloaded via ensure_loaded()

fixed 73oracle.t, added charfield

 * Fixed test cases of ResultSetColumn vs. +select/+as (they used to unconditionally pass).
 * Added a test case of ResultSetColumn for a non-existent column (note: a valid SQL fragment still can be passed instead of a column).
 * Added a test case of ResultSetColumn that tests overriding a column using select/as.
 * ResultSetColumn now respects select/as/+select/+as.
 * Added missing throw_exception() to ResultSetColumn.

Clarify attributes argument of find()

belongs_to relationships are explicitly flagged by default, to aid the DBIC SQLT parser (by abraxxa)

Switch out one more reliance on connect_info

changed the way we get the DSN for debugging in replication

Switch schema management version calls from VERSION() to schema_version()

Don't rely on connect_info(), instead fetch the dsn from _dbi_connect_info (which is stable no matter which connect_info() flavor is used)
todo: ping jnpiorkowski about Replicated::Pool and Replicated::Replicant - it blindly assumes that connect_info->[0] contains the dsn, which might not be the case. Even when using _dbi_connect_info, the first element might be a coderef

Fix detection of multiple rows being returned for single(): calling fetchrow_array in scalar context leads to indefined results (search.cpan.org/~timb/DBI/DBI.pm#fetchrow_array)

Some testdb changes and alignment, preparing for test refactor branch

SQLT behaves sanely in scalar context, no need for stupid version detections (ribasushi--)

More TODO items

One extra multicreate test and some cleanup

Fix loss of objects on multicreate over several 1:M relations

Final insanification of the multicreate test

unhide SQL::Translator::Parser::DBIx::Class from pause indexer

pod documentation for SQL::Translator::Parser::DBIx::Class

A little indentation clean up

Test the result of an eval directly.

discard the changes to $sandl to quiet an "object destroyed with changes"
warning.

mk_group_accessor() is sometimes called internally when inflating a column
and with an array ref field spec, but the accessor and column names are
the same.  Special case that to go through the usual accessor_name_for stuff.

[rt.cpan.org 36863]
Fix mk_group_accessors() to handle [$field, $name].  It ignores
accessor/mutator_name_for() because if you pass in your own accessor
name you probably mean it.

Normalize indentation

And now really untabify

normalize the indentation and detabify

fixed 73oracle.t

Test prompted by discussion about tasty stuff

Better linking in Relatiomship POD

More svn:ignore

Clarify Relationship POD

refactor of t/96multi_create.t:
- simplify test case submitted by wreis
- incorporate it into the large multicreate at the end
- eval{} independent sections of the test so more output can be gathered

Augment commit r5037 - the column_info feature on SQLite is not buggy but partially unimplemented

rolling back my last change, waiting until new sqlt is on cpan

fixed next warnings

updated Changes

split sql statements for deploy only if SQLT::Producer returned a scalar

TODOify a test broken by design, which exposes a bug in virtually all DBD::SQLite versions

added failing test case for multi create

Kill the install process at the MakeMaker stage if a dodgy DBD::SQLite is detected

68inflate_has_a.t tests the cdbi-compat shim and thus belongs in t/cdbi-t
bumped up the version of DBD::SQLite required for testing

Adjust MANIFEST.SKIP

Cleanup TODO, delete implemented VERSIONING.SKETCH

It seems that some CPAN testers have a weird unreleased DBD::SQLite 1.14001 which return unexpected column info - fixing. Should take care of:
http://www.nntp.perl.org/group/perl.cpan.testers/2008/10/msg2525124.html
http://www.nntp.perl.org/group/perl.cpan.testers/2008/10/msg2525137.html