There is no gaurentee that you'll get the same persistant connection unfortunetly. If your browser really used HTTP/1.1 keepalive, you'd stand a better chance of it, but really that is no way to do it.
can anybody tell me more there?
The only workaround that is possible if we want transaction support in PMA would be to buffer the queries inside PMA, using our own seperate table, and then sending them atomically to MySQL on COMMIT or just dumping them on ROLLBACK.
no, i don't think that'd stand a chance - if i have a big table and want to do a updatequery on it and afterwards check if everything looks fine before doing commit or rollback, that'd mean PMA would do a copy of my big table on the heap for as long as it takes me to decide wether i like it? i doubt that any ISP would like that behaviour.
but it is kind of sad, to see that here we seem to come to a point where MySQL is offering a useful feature that users will not be able to use with PMA - for usage of transactions i now installed the MySQL Controlcenter here again ;-(
cheers
Mike Beck
Beck, Mike wrote:
There is no gaurentee that you'll get the same persistant connection unfortunetly. If your browser really used HTTP/1.1 keepalive, you'd stand a better chance of it, but really that is no way to do it.
can anybody tell me more there?
The only workaround that is possible if we want transaction support in PMA would be to buffer the queries inside PMA, using our own seperate table, and then sending them atomically to MySQL on COMMIT or just dumping them on ROLLBACK.
no, i don't think that'd stand a chance - if i have a big table and want to do a updatequery on it and afterwards check if everything looks fine before doing commit or rollback, that'd mean PMA would do a copy of my big table on the heap for as long as it takes me to decide wether i like it? i doubt that any ISP would like that behaviour.
but it is kind of sad, to see that here we seem to come to a point where MySQL is offering a useful feature that users will not be able to use with PMA - for usage of transactions i now installed the MySQL Controlcenter here again ;-(
cheers
Mike Beck
Mike,
it's not only a matter of phpMyAdmin: MySQL transactions are not available for any web-based PHP/MySQL application.
But I remember MySQL.com developers once writing that in practice they did not feel the need for transactions :)
Marc
On Mon, Mar 24, 2003 at 05:57:01PM +0100, Beck, Mike wrote:
The only workaround that is possible if we want transaction support in PMA would be to buffer the queries inside PMA, using our own seperate table, and then sending them atomically to MySQL on COMMIT or just dumping them on ROLLBACK.
no, i don't think that'd stand a chance - if i have a big table and want to do a updatequery on it and afterwards check if everything looks fine before doing commit or rollback, that'd mean PMA would do a copy of my big table on the heap for as long as it takes me to decide wether i like it? i doubt that any ISP would like that behaviour.
so you are doing: BEGIN UPDATE ... UPDATE ... UPDATE ... SELECT (and check results) COMMIT
you are expecting the SELECT to show the effect of UPDATE yes? It shouldn't show any changes to the tables until you do COMMIT.
What we DO need to accomplish the above, is something to check that the queries are 100% valid, without running them.
One other possible solution to this, abusing persistant connections: Is it possible to serialize the connection info in some way, and preserve it in a table maybe? That way it should be portable between Apache instances, or is that asking too much?
but it is kind of sad, to see that here we seem to come to a point where MySQL is offering a useful feature that users will not be able to use with PMA - for usage of transactions i now installed the MySQL Controlcenter here again ;-(
This is only because the transactionless nature of HTTP is conflicting.
-
Beck, Mike -
Marc Delisle -
Robin H. Johnson