});

> I have few places in my models need transaction. however, doing
> following over and over again gets tedious.. I am wondering how do
> other peopel do it?

>     public function delete_news($news_id) {

>         $news = $this->get_news($news_id);
>         if ( ! $news ) {
>             throw new Exception('error_news_not_found');
>         }

>         $con = Propel::getConnection(M_NewsPeer::DATABASE_NAME);
>         $con->beginTransaction();

>         try {
>             $news->setDeleted(1);
>             $news->save($con);
>             $con->commit();
>         } catch (Exception $e) {
>             $con->rollback();
>             throw $e;
>         }
>     }

> I see that doctrine has convience wrapper usage like the following:

> <?php
> // $em instanceof EntityManager
> $em->transactional(function($em) {
>     //... do some work
>     $user = new User;
>     $user->setName('George');
>     $em->persist($user);

> });

> Hey Quiang,

> based on your example I don't think you need a transaction there.
> A transaction is used to ensure 2 or more related changes (usually to
> 2 or more models) are assured to happen together, or not at all.
> In your case you're only updating one model. Imagine it failed,
> there's no inconsistency that you are guarding against, the database
> would be in exactly the same state, whether you roll back or not.

> I know this is not really answering your question, but with that
> feedback in mind you might find that you only need transactions in a
> few places, not everywhere.

> Daniel

> On Feb 27, 2:25 am, Qiang <junkyardp...@gmail.com> wrote:
> > I have few places in my models need transaction. however, doing
> > following over and over again gets tedious.. I am wondering how do
> > other peopel do it?

> >     public function delete_news($news_id) {

> >         $news = $this->get_news($news_id);
> >         if ( ! $news ) {
> >             throw new Exception('error_news_not_found');
> >         }

> >         $con = Propel::getConnection(M_NewsPeer::DATABASE_NAME);
> >         $con->beginTransaction();

> >         try {
> >             $news->setDeleted(1);
> >             $news->save($con);
> >             $con->commit();
> >         } catch (Exception $e) {
> >             $con->rollback();
> >             throw $e;
> >         }
> >     }

> > I see that doctrine has convience wrapper usage like the following:

> > <?php
> > // $em instanceof EntityManager
> > $em->transactional(function($em) {
> >     //... do some work
> >     $user = new User;
> >     $user->setName('George');
> >     $em->persist($user);

> > });

> --
> You received this message because you are subscribed to the Google Groups
> "Propel Users" group.
> To post to this group, send email to propel-users@googlegroups.com.
> To unsubscribe from this group, send email to
> propel-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/propel-users?hl=en.

> Nevertheless, I think Quiang's idea could ease the path for some devs. This
> could be a welcome addition to Propel2, but it introduces a second way of
> doing the same thing (a transaction), and I'm not particularily fond of
> that. It means more documentation, and more confusion for the users.

> What do others think?

> François

> 2012/2/27 Richtermeister <nex...@gmail.com>

> > Hey Quiang,

> > based on your example I don't think you need a transaction there.
> > A transaction is used to ensure 2 or more related changes (usually to
> > 2 or more models) are assured to happen together, or not at all.
> > In your case you're only updating one model. Imagine it failed,
> > there's no inconsistency that you are guarding against, the database
> > would be in exactly the same state, whether you roll back or not.

> > I know this is not really answering your question, but with that
> > feedback in mind you might find that you only need transactions in a
> > few places, not everywhere.

> > Daniel

> > On Feb 27, 2:25 am, Qiang <junkyardp...@gmail.com> wrote:
> > > I have few places in my models need transaction. however, doing
> > > following over and over again gets tedious.. I am wondering how do
> > > other peopel do it?

> > >     public function delete_news($news_id) {

> > >         $news = $this->get_news($news_id);
> > >         if ( ! $news ) {
> > >             throw new Exception('error_news_not_found');
> > >         }

> > >         $con = Propel::getConnection(M_NewsPeer::DATABASE_NAME);
> > >         $con->beginTransaction();

> > >         try {
> > >             $news->setDeleted(1);
> > >             $news->save($con);
> > >             $con->commit();
> > >         } catch (Exception $e) {
> > >             $con->rollback();
> > >             throw $e;
> > >         }
> > >     }

> > > I see that doctrine has convience wrapper usage like the following:

> > > <?php
> > > // $em instanceof EntityManager
> > > $em->transactional(function($em) {
> > >     //... do some work
> > >     $user = new User;
> > >     $user->setName('George');
> > >     $em->persist($user);

> > > });

> > --
> > You received this message because you are subscribed to the Google Groups
> > "Propel Users" group.
> > To post to this group, send email to propel-users@googlegroups.com.
> > To unsubscribe from this group, send email to
> > propel-users+unsubscribe@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/propel-users?hl=en.

> Hi Francois,

> coming from the Perl land familiar with it's popular ORM DBIx::Class,
> I really enjoy the txn_do($coderef) method which takes a code
> reference argument and does:

> Executes $coderef with (optional) arguments @coderef_args atomically,
> returning its result (if any). If an exception is caught, a rollback
> is issued and the exception is rethrown. If the rollback fails, (i.e.
> throws an exception) an exception is thrown that includes a "Rollback
> failed" message.

> copied from
> http://search.cpan.org/~arodland/DBIx-Class-0.08196/lib/DBIx/Class/St...
> the souce code of it is here
> http://search.cpan.org/src/ARODLAND/DBIx-Class-0.08196/lib/DBIx/Class...

> So in the end, it saves developer writing commit and rollback all over
> the places..  hopefully the above could be somewhat a pointer for
> Propel.

> Richtermeister, thanks for pointing that out. agree that transaction
> is not necessary in the above case of single operation.

> cheers,

> On 2月28日, 上午1时25分, Francois Zaninotto <fzanino...@gmail.com> wrote:
> > Nevertheless, I think Quiang's idea could ease the path for some devs.
> This
> > could be a welcome addition to Propel2, but it introduces a second way of
> > doing the same thing (a transaction), and I'm not particularily fond of
> > that. It means more documentation, and more confusion for the users.

> > What do others think?

> > François

> > 2012/2/27 Richtermeister <nex...@gmail.com>

> > > Hey Quiang,

> > > based on your example I don't think you need a transaction there.
> > > A transaction is used to ensure 2 or more related changes (usually to
> > > 2 or more models) are assured to happen together, or not at all.
> > > In your case you're only updating one model. Imagine it failed,
> > > there's no inconsistency that you are guarding against, the database
> > > would be in exactly the same state, whether you roll back or not.

> > > I know this is not really answering your question, but with that
> > > feedback in mind you might find that you only need transactions in a
> > > few places, not everywhere.

> > > Daniel

> > > On Feb 27, 2:25 am, Qiang <junkyardp...@gmail.com> wrote:
> > > > I have few places in my models need transaction. however, doing
> > > > following over and over again gets tedious.. I am wondering how do
> > > > other peopel do it?

> > > >     public function delete_news($news_id) {

> > > >         $news = $this->get_news($news_id);
> > > >         if ( ! $news ) {
> > > >             throw new Exception('error_news_not_found');
> > > >         }

> > > >         $con = Propel::getConnection(M_NewsPeer::DATABASE_NAME);
> > > >         $con->beginTransaction();

> > > >         try {
> > > >             $news->setDeleted(1);
> > > >             $news->save($con);
> > > >             $con->commit();
> > > >         } catch (Exception $e) {
> > > >             $con->rollback();
> > > >             throw $e;
> > > >         }
> > > >     }

> > > > I see that doctrine has convience wrapper usage like the following:

> > > > <?php
> > > > // $em instanceof EntityManager
> > > > $em->transactional(function($em) {
> > > >     //... do some work
> > > >     $user = new User;
> > > >     $user->setName('George');
> > > >     $em->persist($user);

> > > > });

> > > --
> > > You received this message because you are subscribed to the Google
> Groups
> > > "Propel Users" group.
> > > To post to this group, send email to propel-users@googlegroups.com.
> > > To unsubscribe from this group, send email to
> > > propel-users+unsubscribe@googlegroups.com.
> > > For more options, visit this group at
> > >http://groups.google.com/group/propel-users?hl=en.

> --
> You received this message because you are subscribed to the Google Groups
> "Propel Users" group.
> To post to this group, send email to propel-users@googlegroups.com.
> To unsubscribe from this group, send email to
> propel-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/propel-users?hl=en.

> Qiang,

> I recognized your Perl background when you suggested something that may lead Propel to TIMTOWTDI (There Is More Than One Way To Do It), which is the only opposition I have To your suggestion.

> Cheers,

> François

> 2012/2/28 Qiang <junkyardp...@gmail.com>
> Hi Francois,

> coming from the Perl land familiar with it's popular ORM DBIx::Class,
> I really enjoy the txn_do($coderef) method which takes a code
> reference argument and does:

> Executes $coderef with (optional) arguments @coderef_args atomically,
> returning its result (if any). If an exception is caught, a rollback
> is issued and the exception is rethrown. If the rollback fails, (i.e.
> throws an exception) an exception is thrown that includes a "Rollback
> failed" message.

> copied from http://search.cpan.org/~arodland/DBIx-Class-0.08196/lib/DBIx/Class/St...
> the souce code of it is here http://search.cpan.org/src/ARODLAND/DBIx-Class-0.08196/lib/DBIx/Class...

> So in the end, it saves developer writing commit and rollback all over
> the places..  hopefully the above could be somewhat a pointer for
> Propel.

> Richtermeister, thanks for pointing that out. agree that transaction
> is not necessary in the above case of single operation.

> cheers,

> On 2月28日, 上午1时25分, Francois Zaninotto <fzanino...@gmail.com> wrote:
> > Nevertheless, I think Quiang's idea could ease the path for some devs. This
> > could be a welcome addition to Propel2, but it introduces a second way of
> > doing the same thing (a transaction), and I'm not particularily fond of
> > that. It means more documentation, and more confusion for the users.

> > What do others think?

> > François

> > 2012/2/27 Richtermeister <nex...@gmail.com>

> > > Hey Quiang,

> > > based on your example I don't think you need a transaction there.
> > > A transaction is used to ensure 2 or more related changes (usually to
> > > 2 or more models) are assured to happen together, or not at all.
> > > In your case you're only updating one model. Imagine it failed,
> > > there's no inconsistency that you are guarding against, the database
> > > would be in exactly the same state, whether you roll back or not.

> > > I know this is not really answering your question, but with that
> > > feedback in mind you might find that you only need transactions in a
> > > few places, not everywhere.

> > > Daniel

> > > On Feb 27, 2:25 am, Qiang <junkyardp...@gmail.com> wrote:
> > > > I have few places in my models need transaction. however, doing
> > > > following over and over again gets tedious.. I am wondering how do
> > > > other peopel do it?

> > > >     public function delete_news($news_id) {

> > > >         $news = $this->get_news($news_id);
> > > >         if ( ! $news ) {
> > > >             throw new Exception('error_news_not_found');
> > > >         }

> > > >         $con = Propel::getConnection(M_NewsPeer::DATABASE_NAME);
> > > >         $con->beginTransaction();

> > > >         try {
> > > >             $news->setDeleted(1);
> > > >             $news->save($con);
> > > >             $con->commit();
> > > >         } catch (Exception $e) {
> > > >             $con->rollback();
> > > >             throw $e;
> > > >         }
> > > >     }

> > > > I see that doctrine has convience wrapper usage like the following:

> > > > <?php
> > > > // $em instanceof EntityManager
> > > > $em->transactional(function($em) {
> > > >     //... do some work
> > > >     $user = new User;
> > > >     $user->setName('George');
> > > >     $em->persist($user);

> > > > });

> > > --
> > > You received this message because you are subscribed to the Google Groups
> > > "Propel Users" group.
> > > To post to this group, send email to propel-users@googlegroups.com.
> > > To unsubscribe from this group, send email to
> > > propel-users+unsubscribe@googlegroups.com.
> > > For more options, visit this group at
> > >http://groups.google.com/group/propel-users?hl=en.

> --
> You received this message because you are subscribed to the Google Groups "Propel Users" group.
> To post to this group, send email to propel-users@googlegroups.com.
> To unsubscribe from this group, send email to propel-users+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/propel-users?hl=en.

> --
> You received this message because you are subscribed to the Google Groups "Propel Users" group.
> To post to this group, send email to propel-users@googlegroups.com.
> To unsubscribe from this group, send email to propel-users+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/propel-users?hl=en.

> Hi,

>  I like the idea to add a new method on the connection class (transactional(\closure) for instance), it's a convenient way to use transactions, and it really makes sense IMO. But, it's a bit restrictive because you won't be able to use a single transaction everywhere (let's say if you cannot put all of your code in one closure). So we need to keep existing methods, and then we'll provide two ways to use transactions.

> In one hand, Propel has always provided an intuitive, and convenient API. That's why I think it makes sense to add this feature.
> In another hand, it duplicates features, even if it eases things.

> Let's wait more feedback from users.

> My 2cents

> Cheers,
> William

> Le 28 févr. 2012 à 08:46, Francois Zaninotto <fzanino...@gmail.com> a écrit :

> > Qiang,

> > I recognized your Perl background when you suggested something that may lead Propel to TIMTOWTDI (There Is More Than One Way To Do It), which is the only opposition I have To your suggestion.

> > Cheers,

> > François

> > 2012/2/28 Qiang <junkyardp...@gmail.com>
> > Hi Francois,

> > coming from the Perl land familiar with it's popular ORM DBIx::Class,
> > I really enjoy the txn_do($coderef) method which takes a code
> > reference argument and does:

> > Executes $coderef with (optional) arguments @coderef_args atomically,
> > returning its result (if any). If an exception is caught, a rollback
> > is issued and the exception is rethrown. If the rollback fails, (i.e.
> > throws an exception) an exception is thrown that includes a "Rollback
> > failed" message.

> > copied fromhttp://search.cpan.org/~arodland/DBIx-Class-0.08196/lib/DBIx/Class/St...
> > the souce code of it is herehttp://search.cpan.org/src/ARODLAND/DBIx-Class-0.08196/lib/DBIx/Class...

> > So in the end, it saves developer writing commit and rollback all over
> > the places..  hopefully the above could be somewhat a pointer for
> > Propel.

> > Richtermeister, thanks for pointing that out. agree that transaction
> > is not necessary in the above case of single operation.

> > cheers,

> > On 2月28日, 上午1时25分, Francois Zaninotto <fzanino...@gmail.com> wrote:
> > > Nevertheless, I think Quiang's idea could ease the path for some devs. This
> > > could be a welcome addition to Propel2, but it introduces a second way of
> > > doing the same thing (a transaction), and I'm not particularily fond of
> > > that. It means more documentation, and more confusion for the users.

> > > What do others think?

> > > François

> > > 2012/2/27 Richtermeister <nex...@gmail.com>

> > > > Hey Quiang,

> > > > based on your example I don't think you need a transaction there.
> > > > A transaction is used to ensure 2 or more related changes (usually to
> > > > 2 or more models) are assured to happen together, or not at all.
> > > > In your case you're only updating one model. Imagine it failed,
> > > > there's no inconsistency that you are guarding against, the database
> > > > would be in exactly the same state, whether you roll back or not.

> > > > I know this is not really answering your question, but with that
> > > > feedback in mind you might find that you only need transactions in a
> > > > few places, not everywhere.

> > > > Daniel

> > > > On Feb 27, 2:25 am, Qiang <junkyardp...@gmail.com> wrote:
> > > > > I have few places in my models need transaction. however, doing
> > > > > following over and over again gets tedious.. I am wondering how do
> > > > > other peopel do it?

> > > > >     public function delete_news($news_id) {

> > > > >         $news = $this->get_news($news_id);
> > > > >         if ( ! $news ) {
> > > > >             throw new Exception('error_news_not_found');
> > > > >         }

> > > > >         $con = Propel::getConnection(M_NewsPeer::DATABASE_NAME);
> > > > >         $con->beginTransaction();

> > > > >         try {
> > > > >             $news->setDeleted(1);
> > > > >             $news->save($con);
> > > > >             $con->commit();
> > > > >         } catch (Exception $e) {
> > > > >             $con->rollback();
> > > > >             throw $e;
> > > > >         }
> > > > >     }

> > > > > I see that doctrine has convience wrapper usage like the following:

> > > > > <?php
> > > > > // $em instanceof EntityManager
> > > > > $em->transactional(function($em) {
> > > > >     //... do some work
> > > > >     $user = new User;
> > > > >     $user->setName('George');
> > > > >     $em->persist($user);

> > > > > });

> > > > --
> > > > You received this message because you are subscribed to the Google Groups
> > > > "Propel Users" group.
> > > > To post to this group, send email to propel-users@googlegroups.com.
> > > > To unsubscribe from this group, send email to
> > > > propel-users+unsubscribe@googlegroups.com.
> > > > For more options, visit this group at
> > > >http://groups.google.com/group/propel-users?hl=en.

> > --
> > You received this message because you are subscribed to the Google Groups "Propel Users" group.
> > To post to this group, send email to propel-users@googlegroups.com.
> > To unsubscribe from this group, send email to propel-users+unsubscribe@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/propel-users?hl=en.

> > --
> > You received this message because you are subscribed to the Google Groups "Propel Users" group.
> > To post to this group, send email to propel-users@googlegroups.com.
> > To unsubscribe from this group, send email to propel-users+unsubscribe@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/propel-users?hl=en.