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

[Peter Rabbitson]

On Tue, Mar 19, 2013 at 10:51:17AM -0400, Brendan Byrd wrote:
> Of course, I would counter with "Why would anybody need a single-column
> table?"

Sensible, DML-updateable, centralized (i.e. shared between multiple 
tables) ENUM's. You have a single column table with the rows being the 
(unique) enum values. And an FK constraint is declared on very 
table/column that needs this particular ENUM.

> but as with has_one

As I stated earlier - I am absolutely in favor deprecating has_one/might_have
as a way out of the rel declaration debacle (RT#83712)

> we have to support strange DB designs.

Actually we don't unless there is a tangible benefit in doing so. 
Providing multiple DBD's just "because we can" reinforces the disastrous 
notion most programmers have that once they use DBIC for something they 
have to use it for everything. Often reaching out to plain DBI is the 
most sensible and correct approach.

I do understand that providing 80/20 support for e.g. DBD::DBM is easy. 
But if we never can support the remaining "20", is it really sensible to 
invite folks to use DBIC to access their DBD::DBM based store?

Things like DBD::CSV/DBD::Excel - I understand, because they are 
essentially a "degenerate DBD::SQLite". DBD::DBM - less so. Don't get me 
wrong - I am not saying we can't include them on "wikipedia notability" 
grounds. More like given our tradition of "supported once - supported 
forever", I am simply raising the question "to what end?"

Cheers