Idempotent is not Effectless

[ivan-kleshnin]

I think the following is based on wrong assumptions:

Retrieving and setting values in a JSON Graph are both examples of idempotent operations. This means that you can repeat the same set or get operation multiple times without introducing any additional side effects.

Itempotence of an operation like HTTP PUT does not mean that operation has no (data-related) side effects.

For example, you change the product in the admin panel enabling it's checkbox of "TOP product" feature. Now the special list of TOP products must include this new product.

You have that list (of refs) cached. You have to reset this cache or to add a ref to the new product. And this is a side-effect of setValue, which have to occur to keep data relevant: data outside of the setValue focus have to change. We need to be able to update an additional data after set as well we need that after call.

Some idempotent operations can affect derived data.

Through the docs I see even more places where "idempotent" adjective is used as "effectless" while they aren't the same thing.

I think, you guys think that:

• get = side effects aren't possible
• set = side effects aren't possible
• call = side effects are possible

While in reality it's:

• get = side effects aren't possible
• set = side effects are possible at first invocation
• call = side effects are possible for each invocation

As one consequence, for example, this:

The Optional refPaths Argument
Typically, returnValuePaths are used when the function creates a new object and returns a reference to that object. The refPaths can be passed to the call method in order to allow fields to be retrieved from the newly-generated object without the need for a subsequent get operation.

should be applicable to set operations as well.

Note: I don't use Falcor, I'm just a random observer. I'm not sure I get your understanding of "side-effects" exactly correct but nevertheless I think the first quoted paragraph is misleading.

[asyncanup]

@ivan-kleshnin
Note that the paragraph quoted above says "without introducing any additional side effects"
By idempotent, we mean that invoking the operation multiple times produces the same side effects as invoking it only once.

This follows the accepted definition of idempotency in HTTP spec here: https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

9.1.2 Idempotent Methods

Methods can also have the property of "idempotence" in that (aside from error or
expiration issues) the side-effects of N > 0 identical requests is the same as for a
single request.
The methods GET, HEAD, PUT and DELETE share this property. Also, the methods
OPTIONS and TRACE SHOULD NOT have side effects, and so are inherently idempotent.