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

[Peter Rabbitson]

On Tue, Mar 19, 2013 at 11:44:58AM -0400, Brendan Byrd wrote:
> On Tue, Mar 19, 2013 at 11:04 AM, Peter Rabbitson <rabbit+dbic at rabbit.us>wrote:
> 
> > On Tue, Mar 19, 2013 at 10:51:17AM -0400, Brendan Byrd wrote:
> >
> > > 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.

I meant the *helpers*. Read the linked RT [1], especially the part that 
starts with "I need to step back in order to explain this properly..."

Nobody says we will stop supporting odd relationships, I am simply 
lamenting that we do not have an unambiguous way of doing the simple 
stuff.

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

That is something I would like to see some day as well, so no issue there.
However see below (and read my comments from a 10-mile-high viewpoint):

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

I am sorry you mistakenly chose DBIC for such a project. It was not (and 
I very much doubt it can be made) the correct choice for such a task.

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

Sort-of. DBIC has been very cautious on relationships, because of how 
hard it is to make them work properly in real life. That is: just making 
them seamlessly perform within a *single $dbh* has been an insanely hard 
problem, left alone doing efficient cross-$dbh joins etc. So while a 
long-term goal like this is awesome, I am skeptical that DBIC in its 
current or future form is well suited for seamless relationship hopping 
with the apparent ease (but without the limitations of LINQ).

A separate project that builds *on top* of DBIC to provide rudimentary 
cross-schema operation seems like a much saner and safer route (i.e. no 
"backout" strategy is necessary if the design turns out to be a deadend)

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

This would be a "good thing" for a young project that does not have to 
care about existing design desicions nor a massive installed base. In 
the case of DBIC trying to shoehorn things it is decisively not designed 
to do may actually be counter-productive.

As an unrelated example: providing a ::Storage::MongoDB without a much 
better query framework (DQ may or may not deliver that - too early to 
tell) would be a disaster. It would not add any value for the casual 
user over other existing solutions, and encountered limitations would 
cross DBIC off the list of "things to use in the future" even in 
situations where it would be inispensable.

> Heck, we have plenty of RDBMS that don't support the Full Monty of options
> that things like Oracle or Pg support.

Actually we don't - all current DBIC-known backends more or less support 
the coveted "ANSI SQL". Or more correctly DBIC does not strive to 
emulate oddball stuff like custom types, or lat/long data etc. This is a 
job for external plugins.

Core support for something that does not have the concept of transactions is
questionable but doable. Support *via the DBI backend* of something that has
column name/count limitations is much more questionable.

Having a *separate* storage backend for hierarchical data that is better 
accessible via "not-DBI" would make more sense in this situation.

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

Yes, and given the "point" of S::S it absolutely belongs in 
::Storage::DBI. I am not questioning this at all. What I am concerned 
about is that we are trying to provide support for things like DBD::DBM 
which bend the concept of DBD::File almost to a breaking point, while 
S::S already bends DBIC's concepts to another breaking point.

In other words I want to refocus on evaluating each DBD *on its own 
merit*, instead of the way you did it, namely "It is based on S::S".

Cheers

[1] https://rt.cpan.org/Public/Bug/Display.html?id=83712#txn-1187773