You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 16, 2022. It is now read-only.
The com.example.valueentity.shoppingcart.ShoppingCart implements addItem in a way that returns state action updates in the order so that the updated line-item, if it has existed, is positioned at the end of the state action updates list:
This is originated because a shopping cart line-item that already exists is removed and then re-added with the newly updated quantity:
mandate the TCK addItem test case for the shopping cart to be mandated like this
allow the TCK to match list items independently of their order
mandate that the order of the carts state for addItem, and any other, is the order in which the items where added and or removed.
I think I would opt-in for the last option, whereas the second option also could be helpful for certain instances, where the order is not important at all and would not fit a languages idiomatic implementation.
The text was updated successfully, but these errors were encountered:
Yes, agree that there should either be an order mandated, or the test should allow for out-of-order. Order used could be insert order, or could be sorted by product id.
For the CRDT tests in the TCK, I've added a requirement that responses with current state for Sets and Maps have these sorted (and there's a simplification in the tests that Set values and Map keys are strings). This makes it easy for the tests to just compare received message values directly. And then for the added or removed sets in the deltas themselves, these get transformed on the receiving side, to sort these before doing simple direct comparisons — found it easier to transform deeper parts of the message into an expected order, than do order-independent comparisons across parts of the message.
The
com.example.valueentity.shoppingcart.ShoppingCart
implementsaddItem
in a way that returns state action updates in the order so that the updated line-item, if it has existed, is positioned at the end of the state action updates list:This is originated because a shopping cart line-item that already exists is removed and then re-added with the newly updated quantity:
https://github.com/cloudstateio/cloudstate/blob/master/samples/java-shopping-cart/src/main/java/io/cloudstate/samples/shoppingcart/ShoppingCartEntity.java#L58-L59
So adding 2 times
product:2
then 11 ofproduct:1
and then 31 ofproduct:2
emits the following state asValueEntityUpdate
:with the
items:
ordered as shown. This results in the TCK testing this order by the specifics of this implementations detail:https://github.com/cloudstateio/cloudstate/blob/master/tck/src/main/scala/io/cloudstate/tck/CloudStateTCK.scala#L1390-L1412
We could
addItem
test case for the shopping cart to be mandated like thisaddItem
, and any other, is the order in which the items where added and or removed.I think I would opt-in for the last option, whereas the second option also could be helpful for certain instances, where the order is not important at all and would not fit a languages idiomatic implementation.
The text was updated successfully, but these errors were encountered: