[Dbix-class] Evil Storage Hacking

[Matt S Trout]

Brandon Black wrote:
> On 5/22/06, Christopher H. Laco <claco at chrislaco.com> wrote:
>> Apparently, I'm in the mood to spite myself and do things no human
>> should do. Yes, that's right, I'm attempting to hack out a
>> ::Storage::XMLRPC module for self punishment. Why write/use a DBD driver
>> when I can waste even more time doing a DBIC Storage adapter. :-)
>>
> 
> I feel your pain.  Quite some time I tried to the same sort of thing,
> but it was going to be ::Storage::CSV, where connect_info was a
> directory name and tables were CSV files, etc.  I gave up after a day
> or so :)
> 
>> The problem is, look at ::Storage/Storage::DBI makes my soul bleed. Can
>> the wise DBIC monks shed some light on what ::Storage really does... and
>> more importantly, what something like ::Storage::XMLRPC::select() should
>> return?
>>
> 
> ::Storage::DBI::select returns a ::Storage::DBI::Cursor object I
> believe.  A really good starting point is to stare at and think about
> the abstract classes involved here (DBIx::Class::Storage,
> DBIx::Class::Cursor), and how the ::DBI versions are merely
> specializations of those two generic interfaces that provide for the
> generic concepts of "storage" and "cursor".
> 
> There doesn't actually have to be any real SQL at all involved in your
> queries, as long as you can transform the magical syntax of
> ResultSet->search() and friends into some sort of suitable query for
> the backend at hand, and then return a ::Cursor-based object that
> walks through the results.  It was this search-syntax stuff that
> killed my efforts, it looks pretty hard :)

Some poor fule gave me a copy of the SQL::Abstract tests in a branch 
titled "subselects" (thanks Jess!)

So first I get to factor out some of the more hateful bits of S::A to be 
clean, then we launch into making it a multi-stage parse with the 
eventual aim of only needing to re-implement the final stage to support 
$random_query_format.

Yay. more work. And I've got a cold again.