[Dbix-class] SQLA refactor: proposal

[John Napiorkowski]

--- Les Fletcher <les at affinitycircles.com> wrote:

> 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

Postgresql would be easier, since you can write
functions and stored procedures in Perl.

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



      ____________________________________________________________________________________
Be a better sports nut!  Let your teams follow you 
with Yahoo Mobile. Try it now.  http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ