Sean Legassick wrote:
>
> > Could another abstract class that extends DB be
> > created
> > into which all transaction-specific [or fill in your db-specific
> > feature]
> > interfaces could go? This would probably mean mucking w/ BasePeer, but
> > it
> > would mean a hell of a lot less mucking. :)
>
> This sounds like a good idea for the actual transaction stuff
> (begin/commit/rollback). Clearly some thought needs to be put into a
> reasonable design for transaction handling in BasePeer - most of the
> elements are here in this thread as far as I can see, they just need
> putting together into a coherent plan.
>
OK, Here are the issues that aren't resolved:
1) Should the connection for the transaction be stored within BasePeer
(through some sort of static Hashtable keyed on a transactionID) or
through a new non abstract class?
2) Should the check for whether transactions are needed (i.e. for
postgres) be done within BasePeer, or in a higher level peer?
3) Should the check be:
a: Is it postgres
b: Check some method in the DB implementation (objectDataNeedsTrans)
4) should we also check if there's a large object in the table, and only
set up a transaction then , or always do transactions on postgresql?
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
