On 28/02/13 02:29 AM, Serguei Osokine wrote: > On Wednesday, February 27, 2013 ianG wrote: >> Code-wise, it is hard to deal with quite so philosophically, it has >> to fall as either an error or a success not both. >> >> Does anyone feel they've got a lock on which it should be? Or >> should I implement a tri-state :( ? > > Sounds like it depends on your application and on the purpose of this > operation. It can be an error, or it can be a success, depending on > whether you're satisfied with the result (i.e. all you want is an ID > or handle to the open file "foo" regardles of whether it was created > before) or not satisfied with it (maybe you want to create the file > "foo" with a guarantee that it did not exist before).
The issue that occurs at high level is that networks look at this issue in one way, and databases look at it in another way. Possibly for good reasons. When we meld the two together, this perspective distinction creates an impedance mismatch. Databases tend to say you can create a record, and access a record that is created. Networks tend to say that you can cause an action, idempotently. Databases tend not to use the idempotent language. (See James' post for the network context, and some singing to the choir about TCP being a pretty poor excuse for a large datagrams protocol.) > These are semantically different operations - so first of all, you > have to decide for yourself which one of them is the one that you > want to perform, and treat its result accordingly. For example, > Linux open() call uses O_EXCL flag to explicitly specify which > semantics of the fiel creation operation is to be used. Right, it all depends. The fix I've come up with is that the lower layer (the protocol objects) returns its "you cannot create that coz it is already created" error. The middle layer (the internal queuing code) then conflates success with that single above error (by means of extending the isError() method) and labels both of those as success. The higher layer carries on with happiness and simplicity. So far it works fine! Good to think it out in forum, thanks to all. iang > (That is, if I did understand your problem correctly.) > > Best wishes - > S.Osokine. > 27 Feb 2013. > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of ianG > Sent: Wednesday, February 27, 2013 5:10 AM > To: [email protected] > Subject: [p2p-hackers] is Idempotent/Already a success or failure? > > Hi all, > > I'm wrestling with a protocol error condition where an action has been > done already, the requester innocently asks for it to be done, and is > told that it is already done. Idempotency, in a nutshell. > > The problem with "already done" in an idempotent sense is that it is > both an error and a success. > > Code-wise, it is hard to deal with quite so philosophically, it has to > fall as either an error or a success not both. > > Does anyone feel they've got a lock on which it should be? Or should I > implement a tri-state :( ? > > I'm currently tracing an instance of "create account" that is wending > its way up through layers of results, and it's getting a bit confused. > > iang > _______________________________________________ > p2p-hackers mailing list > [email protected] > http://lists.zooko.com/mailman/listinfo/p2p-hackers > > Confidentiality notice: This message may contain confidential information. > It is intended only for the person to whom it is addressed. If you are not > that person, you should not use this message. We request that you notify us > by replying to this message, and then delete all copies including any > contained in your reply. Thank you. > _______________________________________________ > p2p-hackers mailing list > [email protected] > http://lists.zooko.com/mailman/listinfo/p2p-hackers > _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
