Perrin Harkins wrote:
> On 3/16/07, Christopher H. Laco <[EMAIL PROTECTED]> wrote:
>> So, I have my Cat models all
>> provide commit() and rollback().
>
> I wouldn't do that. This is a function of your database connection,
> not of individual row objects. DBI already provides commit/rollback,
> and that's the level where it should stay.
>
>> Now, I want to use my models outside of Catalyst, let's say in a perl
>> script. Now I have to write yet another block of code to do monitor
>> success/failure, and call commit()/rollback().
>
> Sure you have to call commit -- it's a new set of database
> interactions, with possibly different commit points. Monitoring
> success is usually pretty easy with RaiseError turned on.
>
>> Now, I can wrap my models in yet another wrapper to do what the cat
>> controller and the perl script just did....but now that model is unaware
>> about the script that uses IT. Now I have to write more code, to call
>> the code to call commit/transaction. And so on an so forth.
>
> You totally lost me on that one.
>
>> It just seems like with all of the
>> ORMS out there and all of the ways to use 'schema classes' from them,
>> doing transactions in levels (or multiple levels above) is clumsy at
>> best.
>
> I assume you're talking about the faked multiple levels of commit that
> DBIx::Class provides. The simplest answer is to just stay away from
> all that stuff. Do the commits yourself, at the highest level. Keep
> it out of your O/R mapper objects.
>
> The longer answer is that since nothing but my own code ever touches
> transactions in my environment, I make rules that allow me to write
> reusable code. I keep all of it out of my O/R tools. I turn
> AutoCommit on. When I'm in a high-level routine and I want to make
> several operations transactional, I turn it off with local
> $dbh->{AutoCommit}. If I want to reuse that code from a context where
> a transaction might be active already, it nests perfectly.
>
> I expect you could do something similar with DBIx::Transaction,
> although it sounds more manual to me. And yes, you'll have to get
> your hands on the dbh. No way around that.
>
> - Perrin
>
> But doesn't that act of using a raw dbh from inside of a model, defeat the purpose of models/MVC to begin with?
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
