On Thu, Nov 15, 2012 at 8:47 PM, Andy McCurdy <
sed...@gmail.com> wrote:
> This probably breaks redis-py, but it's not difficult to fix. I agree with
> Josiah however -- when I'm wearing my app developer hat (not as a client
> developer), I only want to see an error at EXEC time, not on all the
> individual commands that I'm queuing up. This already happens in redis-py as
> commands are buffered in the client until EXEC is called, but other clients
> may not be doing this.
I don't like to break redis-py at all... I think this will force me to
just operate a minor design change. Basically when EXEC fails because
it was dirty due to previous errors it will reply with an error like:
-EXECABORT Transaction aborted due to previous errors, please use DISCARD.
About EXEC time error, yes it is a good idea and it is what my branch is doing.
What is a bad idea IMHO is to reply to QUEUED to every command even in
the presence of errors.
Why it is a bad idea? Because it leaves us with two alternatives that
are both bad:
1) Just reply with a generic error at EXEC time.
2) Accumulate errors and reply to all the error at EXEC times, but
Redis errors are single lines.
There is nothing wrong in providing the detailed error ASAP as it
happens, but still reply with a final generic error at EXEC time.
A client should act like this:
1) Send the commands.
2) Get get the N+1 replies (N queued + 1 for EXEC).
3) Check only the last reply, if it's ok we don't care and return a
success code to the caller.
4) If the last reply is -EXECABORT or any other error, parse the rest
of the replies and also provide detailed informations about all the
errors encountered.
This seems really sane to me, and offers other clients that want to
behave differently the ability to also terminate the transaction ASAP
if needed.
> I would like to raise one other issue related to this. From what I have
> seen, most users equate MULTI+EXEC to START TRANSACTION+COMMIT in a
> relational database. Specifically, they expect that if any command fails
> when EXEC is called that NONE of the commands in the multi+exec will affect
> the data inside Redis.
>
> I receive bug reports and emails about this issue regularly, to which I
> respond with "this is how Redis works.." and point them to the section
> "Errors inside a transaction" section of
> (
http://redis.io/topics/transactions). However, as a user, this is the
> behavior I expect and want when I think about transactions. And I believe
> it's what most other people expect and want.
It is inevitable that when people hear "transaction" will think
SQL-wise, but this is not something that should force us to add into
Redis rollbacks that are complex and useless in the case of Redis as
commands can fail only for type mismatch and other erros like this.
if you have a type mismatch, there is an error in the *logic* of your
app. It's like calling SADD instead of SREM. No body can save those
users from application mistakes, only debugging. To add a complex
mechanism just to save them during development and just for a subset
of cases is not the way to go IMHO.
> Apologies for the tangent
Offtopic is my live stile :-) And btw your comment seems very on-topic to me.
Thanks for discussion another point, we are here to chat about Redis!
Salvatore