[Dbix-class] SQL::Abstract 1.x subqueries patch

Ash Berlin ash_cpan at firemirror.com
Mon Nov 3 12:28:40 GMT 2008


On 3 Nov 2008, at 11:46, BUCHMULLER Norbert wrote:

> On Fri, 31 Oct 2008 23:48:56 +0100 Peter Rabbitson
> <rabbit+list at rabbit.us> wrote:
>
>> There is a mostly-working-1.x-rc at
>> http://dev.catalyst.perl.org/repos/bast/SQL-Abstract/1.x/branches/1.50_RC 
>> .
>> Patches should be made against it afaik, although it is very possible
>> this particular bit has been already implemented.
>
> OK, I didn't know about this RC (I just checked 1.x/trunk and 2.000
> trunk).
>
>> Also the branch suffers from major shortage of volunteers. It  
>> passes its
>> own tests but fails reather hard if subjected to the test suite of
>> dbix-class (i.e. added to PERL5LIB before running make test on the  
>> dbic
>> trunk). So if you can spend some cycles on it, it would be rather
>> fantastic.
>
> I've started to investigate & fix some bugs, but it seems that some of
> them require modifications to DBIC as well. What's the policy (plan)
> here? Can I modify DBIC in such a way that breaks compatibility with  
> older
> SQLA versions, or should I attempt to make 1.50 behave the same as  
> prior
> versions instead (so that DBIC can work with both an older SQLA or  
> 1.50)?
>
> You know there's an adaptor module DBIC::SQL::Abstract defined in
> lib/DBIx/Class/Storage/DBI.pm that contains mostly code that should go
> into SQL::Abstract - in fact a comment at the beginning confirms  
> that it
> is just a temp hack. Now this module calls private, undocumented  
> methods
> of SQLA, and some of those are either gone or behave differently. The
> cleanest solution would be to migrate to SQLA those part of the code
> that are useful in general, and add some more public methods to SQLA
> where necessary (eg. C<condition(\%where)> that only returns the
> condition, witout the 'WHERE' word prepended to it). But that will  
> break
> compatibility with older SQLA versions for granted.
>
> I'm going to take care of the conversion of DBIC test cases to use
> SQL::Abstract::Test. I didn't know about the existence of this piece  
> of
> canned magic :-), but I like it very much.
>
> norbi

Yeah, I think the best plan of attack is to move as much out of  
DBIC::SQL::A as possible, and then bump the dep on DBIC to SQL::A  
1.50. If you are going to make changes to DBIC, can you please so on a  
branch (assuming you have commit access, if not ask mst for it)

-ash




More information about the DBIx-Class mailing list