--- Les Fletcher <[EMAIL PROTECTED]> 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/[EMAIL PROTECTED] > > _______________________________________________ > 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/[EMAIL PROTECTED] > ____________________________________________________________________________________ Be a better sports nut! Let your teams follow you with Yahoo Mobile. Try it now. http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ _______________________________________________ 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/[EMAIL PROTECTED]
