|
From: Markus H. <mar...@mh...> - 2005-09-01 21:34:51
|
[I've cc'ed the list as this is of general interest. Please keep these discussions on the list. The discussion will be archived and it is open for everyone to join in] Henrique writes: > The functions proposed was: > > dbi_conn_commit(dbi_connt conn); > dbi_conn_rollback(dbi_conn conn, const char > *savepoint); > dbi_conn_rollback_all(dbi_conn conn); > dbi_conn_set_savepoint(dbi_conn conn, const char > *savepoint); > > Though, I think that we "must" offers a "native" > transactions support instead "const strings" > savepoints, something like creating a new > dbi_transaction data type, what do you think? > Sure, if you can handle this transparently. We need a similar abstraction for auto-incrementing columns which in some engines require that you know the name of the sequence. > Note that sqlite driver will be a problem, since it > don't offers a complete transactions support, so we'll > can works with one, and only one, opened transaction > at time :( > Not only SQLite. mSQL does not support transactions at all. MySQL supports transactions only since approx. 4.0, and only if you use a transaction-safe table type. If you run the fastest tables (MyISAM), there is no transaction support (although sending a BEGIN or COMMIT does not seem to cause an error). > An another thing, I was thinking about offers tables > and columns management, i.e, the library's user don't > will need create and use tables and its columns by > simple query strings, a dbi datatype will be provide > for this. I don't have a plan to this, but if you > like the idea I can create some document or works more > on this. > Could you please elaborate on this a little further? I'm not sure whether I understand you here. > PS: Sorry by my bad, very bad, english > Don't worry. The Portugese of most list subscribers is far worse. All simply do their best. regards, Markus -- Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de |