Test for ordering of log

[bieniusa]

Responsible: Manuel
Collaborator: Alejandro

[angbrav]

I have checked this property in dets.

It works as expected if we use insert_next instead of insert. The problem of using insert is that in case of trying to insert duplicates, it will move the duplicated operation to the tail of the list instead of leaving it where it was originally placed.

For instance, lets say we insert operations in the following order: op1 -> op3 -> op4 -> op2 for key floppy. A look up over floppy key will return [op1,op3,op4,op2]. But if we insert op3 again, by using the regular insert, the lookup would return [op1, op4, op2, op3] while using insert_new, the look up will still return [op1,op3,op4,op2] which the desired output.

I have changed all inserts by insert_new. Please keep this on mind.

I will close this issue

[angbrav]

I was only half right!

I was right saying that by using insert, the order is not preserved when duplicate inserts. Nevertheless, I was wrong saying that insert_new solves the problem.

I have modify it once more. Now, before inserting, the logging_vnode first check whether the operation has been already log. In case it is already logged, it just ignores the operations and return success.

I am pretty sure it works properly now.

[cmeiklejohn]

It would be super nice to write a QuickCheck property for this.

[cmeiklejohn]

Can you just write a quick riak_test to assert this behavior is true so we can prevent against regressions? Then we will close this one out.

[angbrav]

Actually, I think I cannot do it. The tricky part of this is when inserting duplicated operations. From the API there is no way to do that so I cannot generate a test. Plus, the API only allows us to get the object materialised, in order to further test this from riak_test, I would need to expose an operation that returns the list of operations without materialize.

Please correct me if I am wrong and give some hints on how to do it.

[angbrav]

I was rethinking ad retesting this. The current implementation only ensures order per key and not per partition. Do we need it per partition? In that case I think we would need to modify the way we store thinks because in the way we do it now and using sets, I would say is not possible.

[bieniusa]

Probably fixed with the new log version.

[cmeiklejohn]

Marking this finished, as it related to the older version of the logging virtual node.