|
From: Henrique <on...@ya...> - 2005-09-10 14:57:19
|
> I don't see a reson for this. The engines will handle > transactions internaly the only thing needed to be > provided by the libdbi user is the name of the > savepoint so that she/he can rollback with that > savepoint as an argument. Ok. Though, like I as said, isn't all databases that will offers support to savepoints, but all of them offers (a minimum) support to transactions. So, maybe makes sense create news functions to API that *all* databases implement, and not what only one or two do. By other side, I think that savepoints is something that is really in the roadmap for the "toy" databases and seems that is more interesting works with it instead pure transactions > A transcation will only be tied to a connection > anyway so why extract it in to some other level > where it doesn't belong? My initial (bad) idea was offers savepoints support based in sample transactions for databases that don't support this. So, removing the functions for savepoints and implementing only a "native support" for transactions seems the right way. But, as you said, we don't will implement an interface for a support that don't exists in the real database, or in another words, we don't will implement savepoints if the database doesn't support this. > I think the interface provided in your email is > a sane way of implementing transaction support. Yeah. I think the same now. -- Henrique __________________________________________________ Converse com seus amigos em tempo real com o Yahoo! Messenger http://br.download.yahoo.com/messenger/ |