[Dbix-class] SQLA refactor: proposal

Wade.Stuart at fallon.com Wade.Stuart at fallon.com
Tue Nov 27 18:13:22 GMT 2007



Darren Duncan <darren at DarrenDuncan.net> wrote on 11/26/2007 10:26:04 PM:

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

I do hope you are not recommending any type of dynamically created stored
procedure backend?  The idea of my ORM making fugly dynamic stored
procedures all over the place makes me long for SQL + DBI.  As far as my
view on it -- if I want to optimize something down to a SP I would create
it by hand (usable in my perl app and other db apps) and then call it via
DBIC's already exposed API.



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