My initial thoughts were:
1. Use doXXX(Criteria) if you did not need a transaction
2. Use doXXX(Connection, Criteria) if you do need a transaction.
I did not like having a transaction defined for one very specific reason,
when there was not a general method for using transactions. And now, I
would not like the doXXX(Criteria) methods to have a bunch of conditionals
to set up transactions in various circumstances. Though I guess one is not
so bad, If no one else here is opposed, go ahead.
----- Original Message -----
From: Nissim <[EMAIL PROTECTED]>
To: Turbine <[EMAIL PROTECTED]>
Sent: Monday, July 03, 2000 3:36 PM
Subject: Re: Transactions
> Nissim said:
>
> > > 4) in the BasePeer methods that return stuff from the db but don't
take
> > > a connection argument, check first if objectDataNeedsTrans, then if
> > > that's true, check if any of the tables in the criteria
> > > containsObjectColumn, and if that's true, set up a transaction.
> > >
>
> John McNally wrote:
> >
> > 4. I was thinking that TurbineUserPeer and possibly anywhere else
(this
> > should be minimized) that is using the Visitor table should perform
these
> > tasks.
> >
>
> But then any other applications that use large objects and BasePeer will
> have the same problems. The only additional code running in BasePeer
> for non-postgres users is the if (db.objectDataNeedsTrans())...the rest
> is only run for postgres users...
>
> -Nissim
>
>
> ------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
> Problems?: [EMAIL PROTECTED]
>
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
