Sean Legassick wrote:
>
> On Thu, Jun 29, 2000 at 09:09:04AM -0700, John McNally wrote:
> > I think that the transaction support should be general. There is only one
> > column in Turbine, at the moment, that requires a transaction on one
> > database. There should be a generic adaptor method supportsTransactions or
> > hasTransactions. In the code that updates this column we check for support
> > and then use a transaction if it is ok.
>
> If I understand you correctly, the problem with this is that it
> introduces the overhead of a transaction when reading/writing the object
> data column for *any* database that supports transactions, not just
> Postgres. This seems undesirable to me.
>
Are you both saying that BasePeer should remain as it is in the last
patch I submitted, with transactions, but with no special code for large
object support? Then the large object hack should go in the higher level
peer class, but use a method on the db which says hasTransactions()?
Also, I call your attintion to the fact that there already is database
specific code in the TurbineUserPeer:
168 if (
TurbineResources.getString("database.default.driver", "" )
169 .startsWith("oracle") )
170 {
171 id = getNextId(SEQUENCE_NAME);
172 criteria.add(VISITOR_ID, id);
173 BasePeer.doInsert(criteria);
174 }
If that's OK, we can also put code in there which calls the transaction
methods if:
TurbineResources.getString("database.default.driver", "" )
.startsWith("org.postgres")
In any event, I think the BasePeer portion of the patch should be
applied, since it is generic support of transactions...
-Nissim
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
