Nissim wrote:
>
> I looked at that old message...some comments: First of all we need
> transaction functionality on select as well as insert, so I guess we'll
> add methods for doTransactionSelect, doTransactionInsert,
> doTransactionUpdate and doTransactionDelete. While this will be fine to
> fix the postgres prob. It's not really useful for many types of
> transactions, for example if you want to update something, then delete
> something, and then update something else, all in one transaction, it
> would be impossible. I guess we can start with this implementation, and
> then later create a class which contains an ordered list of database
> operations which should happen within a transaction.
I would say go straight to number two (list of db operations), as it
seems to me to be a superset of and replacement for single operation
transactions. Duplicate APIs should not be introduced--public
interfaces should be kept as narrow as possible. Since multiple
operations in a transaction also support single operations, why not
create the multiple operations API but have it start out only allowing
single transactions? Just throw a NotYetImplementedException for now
when people try using this API to batch multiple operations in a single
transactions. This way, we never have to deal with remaining backwards
compatible with the single operation API.
Just my $.02. :)
--
Daniel Rall <[EMAIL PROTECTED]>
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
