search

seyyed / scalaris

Automatically exported from code.google.com/p/scalaris
Apache License 2.0
0 stars 0 forks source link

cs_api_v2:process_request_list does not return a result for commit #64

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
1.  Call cs_api_v2:process_request_list with a write and a commit
2. The results include only a confirmation for the write
3. Whereas v1 used to also send a confirmation for the commit.

What is the expected output? What do you see instead?

I would like to also see the commit confirmation. It's a better programming 
model.

What version of the product are you using? On what operating system?

r1049

Please provide any additional information below.

Also, please switch the JSON interface to use v2.

Original issue reported on code.google.com by natalija...@gmail.com on 27 Aug 2010 at 11:56

GoogleCodeExporter commented 8 years ago 
Results contain also a confirmation for the commit:

> cs_api_v2:process_request_list(cs_api_v2:new_tlog(), [{write, "B", 7}, 
{commit}]).
{[{rdht_tx_write,"B",value,7,6}],
 {results,[{write,"B",{value,7}},commit]}}

The 'commit' is the confirmation for the commit. Otherwise it would have been 
'abort'.

In v1 it looked the following:
> cs_api:process_request_list(cs_api:new_tlog(), [{write, "B", 7}, {commit}]).
{[{write,"B",ok,7,2}],
 {results,[{write,"B",{value,7}},{commit,ok,{value,"ok"}}]}}

But the ok and {value, ok} are unncessary redundant.

v2 is still experimental until issue 56 is implemented. Then we will switch all 
APIs and drop the old tx things in transstore directory.

Original comment by schin...@gmail.com on 27 Aug 2010 at 1:07

GoogleCodeExporter commented 8 years ago 
I should have been clear, I'm talking about the JSON response. A single 
"commit" poses the problem of not having a associated value. How is that going 
to be represented in JSON? So, perhaps, it should be {commit, "ok"} or 
something like. Also, v1 had the "reason" of the failed commit.

As for the redundant part, sure.. but at least design a interface that is 
consistent. A different style for one out of the three members of the results 
is just plain annoying. The less special cases, the better is the programming 
model (in languages other than Erlang).

Original comment by natalija...@gmail.com on 27 Aug 2010 at 5:18

GoogleCodeExporter commented 8 years ago 
Speaking of redundancy, why is the value (of a write) sent back?

Original comment by natalija...@gmail.com on 27 Aug 2010 at 5:19

GoogleCodeExporter commented 8 years ago 
Also, while we wait for issue 56, would it be possible to add _v2 variations 
for JSON? It would make testing easier and goes in line with having 
cs_api/cs_api_v2. Shouldn't take much effort...

Original comment by natalija...@gmail.com on 28 Aug 2010 at 11:55

GoogleCodeExporter commented 8 years ago

Original comment by nico.kru...@googlemail.com on 1 Sep 2010 at 3:32

GoogleCodeExporter commented 8 years ago 
We now have a more clean interface for the transactions, also available via 
JSON.
We removed the redundancy and made the results more consistent.

Original comment by schin...@gmail.com on 7 Mar 2011 at 11:54

GoogleCodeExporter commented 8 years ago 
the changes have been documented in r1607

Original comment by nico.kru...@googlemail.com on 25 Mar 2011 at 9:03