On 28.08.2012 06:16, Aaron Schulz wrote:
I'd have to see what you are doing to see if rollback is really needed.
As far as I see, nested transactions are needed, but no rollback. at least not
from our side.
So, for that case, a simple counter would be sufficient. I still wonder why that
feature
May i barge into this discussion a bit and please, feel free to shut
me down if i'm missing a point here.
I'm failing to see why all this debate. We already have transactions, we
have begin, commit and rollback in the abstraction (Database.php lines
2830+). And this works. All that needs
I'd have to see what you are doing to see if rollback is really needed.
--
View this message in context:
http://wikimedia.7.n6.nabble.com/Nested-database-transactions-tp4983700p4984075.html
Sent from the Wikipedia Developers mailing list archive at Nabble.com.
I was also thinking about introducing a similar functionality, not
exactly nested transaction but just a way to prevent $db-commit and
$db-rollback from doing enything.
Akshay(my GSoC) wanted to have his extension code transaction safe, but
there was just no way of doing it without tinkering
On 23.08.2012 22:49, Brion Vibber wrote:
Well, the main reason is probably that MySQL doesn't support nested
transactions... trying to simulate them with a counter sounds fragile, as a
single rollback would roll back the entire transaction tree, not just the
last
nested one you started (or
On 24.08.2012 03:14, Aaron Schulz wrote:
SAVEPOINTs are useful if we really need to support people rollback
transactions *and* we need nested transaction support. I think they could be
made to work, but I'm not sold on their necessity for any use cases we have.
So, how would you solve the use
So, how would you solve the use case I described? What I need to do is to
perform some checks before calling WikiPage::doEdit, and make sure the
result of
the check is still valid when the actual save occurs.
SAVEPOINTs are basically nested transactions. Can you describe the use case
in more
On 24.08.2012 18:55, Tyler Romeo wrote:
So, how would you solve the use case I described? What I need to do is to
perform some checks before calling WikiPage::doEdit, and make sure the
result of
the check is still valid when the actual save occurs.
SAVEPOINTs are basically nested
On Thu, Aug 23, 2012 at 1:37 PM, Daniel Kinzler dan...@brightbyte.dewrote:
I think it would be extremely useful to allow nested database transactions
- or
simulate them using a counter that would only to the actual commit after
commit() has been called as many times as begin() was called
We solve this in Phabricator by using BEGIN (depth 0) or SAVEPOINT (depth 1+)
when incrementing the counter, ROLLBACK TO SAVEPOINT (depth 1+) or ROLLBACK
(depth 0) when decrementing it after a failure, and nothing (depth 1) or COMMIT
(depth 0) when decrementing it after a success. Our
On Thu, Aug 23, 2012 at 2:02 PM, Evan Priestley epriest...@phacility.comwrote:
We solve this in Phabricator by using BEGIN (depth 0) or SAVEPOINT (depth
1+) when incrementing the counter, ROLLBACK TO SAVEPOINT (depth 1+) or
ROLLBACK (depth 0) when decrementing it after a failure, and nothing
Also, as a matter of record, I just checked and the SAVEPOINT command (or
an equivalent) is supported on SQLite, Postgresql, and mssql.
*--*
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | tylerro...@gmail.com
On Thu, Aug 23, 2012
On 23/08/12 23:21, Brion Vibber wrote:
On Thu, Aug 23, 2012 at 2:02 PM, Evan Priestley
epriest...@phacility.comwrote:
We solve this in Phabricator by using BEGIN (depth 0) or SAVEPOINT (depth
1+) when incrementing the counter, ROLLBACK TO SAVEPOINT (depth 1+) or
ROLLBACK (depth 0) when
Hey,
One concern I have with big transcations that have lots of stuff in them is
that some code might get called in which needs to run in a transaction with
a higher isolation level then the current one. For MySQLs InnoDB the
default is repeatable read, so if you have code that requires
On 23/08/12 23:54, Jeroen De Dauw wrote:
Hey,
One concern I have with big transcations that have lots of stuff in them is
that some code might get called in which needs to run in a transaction with
a higher isolation level then the current one. For MySQLs InnoDB the
default is repeatable
On Thu, Aug 23, 2012 at 02:02:41PM -0700, Evan Priestley wrote:
We solve this in Phabricator by using BEGIN (depth 0) or SAVEPOINT
(depth 1+) when incrementing the counter, ROLLBACK TO SAVEPOINT (depth
1+) or ROLLBACK (depth 0) when decrementing it after a failure, and
nothing (depth 1) or
I'm not saying we have any such code, I'm asking what to do when one wants
to introduce such code. It's entirely feasible some new functionality
requires serializable transactions, so we might want to keep that into
consideration.
Sent from my Android phone.
On 24 Aug 2012 00:30, Platonides
The counter idea kind of reminds of what I have in
https://gerrit.wikimedia.org/r/#/c/16696/ .
I think the whole implicit commit issue is definitely pretty annoying and I
wish there was a reasonable way to address it without reasonable backwards
compatibility. rollback() is the hard case to deal
18 matches
Mail list logo
