[Dbix-class] SQLA refactor: proposal

Les Fletcher les at affinitycircles.com
Tue Nov 27 04:49:10 GMT 2007


Big fan of the adding stored procedure support.  Don't know a tremendous 
amount about the  internal workings or syntax for stored procedures, but 
I do understand the value they offer.  I also don't think that it is a 
big leap from my knowledge to say that the different SQL dialects do 
them differently.  Would this provide an interface for people to put in 
the dialect specific implementations or would there be some generic 
interface here?

Les

Darren Duncan wrote:
> At 12:31 PM -0800 11/26/07, Darren Duncan wrote:
>> At 3:42 PM +0000 11/26/07, Matt S Trout wrote:
>>> I'd hope that we can also look at sharing much of the MuldisD -> SQL 
>>> code
>>> with your SQL DBMS Muldis::DB backend code later, but that's a 
>>> 'would be
>>> nice' not a primary target.
>>
>> I highly recommend this design approach [, to generate Perl 
>> routines,] to the SQL::Abstract rebuild on the generator side if you 
>> want to have the fewest useability issues,
>
> As a corollary to this, and particularly if you're looking for 
> something that is less directly connected to DBI or Perl, and can be 
> worked with more like SQL::Abstract usually is, where it just 
> generates SQL ...
>
> I alternately or additionally recommend generating SQL stored 
> procedures where it is reasonable to do so.
>
> Generally speaking, doing SQL statements in stored procedures have a 
> lot of advantages over not doing so, including easier reusability, 
> speed, security, and so on.
>
> And now, most DBMSs that we would be likely to target have native 
> stored procedure support, even MySQL, so there is less reason not to 
> support them.
>
> Cross-DBMS portability isn't an excuse for not doing so either, since 
> you can generate stored procedures from an abstract AST the same as 
> you can database schema tables or queries or DML.
>
> Any time you know in advance all the SQL that an application will do, 
> if done as stored procedures, you can include this stuff as part of 
> the schema definition, at least when you use DBIx-Class et al to 
> generate your database schema for you.  So then you don't have to keep 
> regenerating the query SQL at run time.
>
> Emphasis on stored procedures is one main design aspect of Muldis D, 
> and something I recommend we do as well.
>
> As for DBMSs without stored procedure support, or where you don't want 
> to alter the pre-existing schema, well then there is the generated 
> Perl subs solution that I previously mentioned.  And whichever is 
> used, the users generally don't have to know, as from their point of 
> view they are just invoking routines when accessing the database.
>
> -- Darren Duncan
>
> _______________________________________________
> List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
> IRC: irc.perl.org#dbix-class
> SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
> Searchable Archive: 
> http://www.grokbase.com/group/dbix-class@lists.rawmode.org



More information about the DBIx-Class mailing list