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

[Brendan Byrd]

On Tue, Mar 19, 2013 at 11:04 AM, Peter Rabbitson <rabbit+dbic at rabbit.us>wr=
ote:

> 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)


Nah, some people have DB designs that they don't have any control over, yet
are pretty complex relationally.  Larger corporate environments are like
that.


> > 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 somewhat disagree.  Once you are dealing with relationships between
tables, DBIC is probably a good idea.  I have this grand vision that all
large sums of data someday end up in DBIC, with foreign cross-references
everywhere.  Case in point: my first time working with DBIC, I was faced
with the challenge to take data from:

* JSON (via Google, from two different sources/queries)
* SNMP
* Oracle
* An internal caching DB (which was at first going to be Fusion Tables, and
then ended up in Oracle, but was tested in SQLite first)

And marry all of that together.  Granted, my goal of creating three
different DBDs for that was probably a little, ahem, ambitious.  But, given
that DBIC is the "relationship master", it still makes sense long-term.


> 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?
>

It encourages its use and potentially invites patches and fixes on the DBD
side to support what it can't support right now.  Or, if DBIC Storage is
the better route, it might encourage patches on our side.  We'll have to
gauge which part of the 20% is too complex to support long-term or not.

Heck, we have plenty of RDBMS that don't support the Full Monty of options
that things like Oracle or Pg support.  Granted, S:S is probably going to
be our low bar (which I wouldn't want to get much lower).  But, it does
provide a hook into the world of abstract data management.

(I do want to improve S:S to work and parse mostly like a real RDBMS, but
that's a longer-term project.)

-- =

Brendan Byrd <Perl at ResonatorSoft.org>
Brendan Byrd <BBYRD at CPAN.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/dbix-class-devel/attachments/201303=
19/2538551f/attachment.htm