Client API refactoring

[peterzeller]

Addressing some suggestions given by Paolo and some other things:

Backwards-compatible changes:

• Make sure that all places that take a ValueCoder also have an overload which uses utf8-strings as default encoding.
• Add some more default ValueCoders for Integers, Enums, Id-Types (classes wrapping a string).
• Document the methods that can throw an AntidoteException.

Mostly compatible:

• Refactor the code, so that methods from internal interfaces are not visible in the public interface.
• Let CrdtMap implement java.util.Map

Breaking changes:

• Rename noTransaction to automaticTransaction
• Remove subtype-relation between ObjectRef and ResponseDecoder (this should get rid of some unnecessary methods on RegisterRef, MapRef and so on)

[mweberUKL]

Regarding the database update and query DSL (also referred to as "immutable interface" in the context of Antidote), a way to group together multiple key-updates into a single map update would be helpful. At the moment there is no way to issue a map-update that updates more than one key in the map.

[peterzeller]

(also referred to as "immutable interface" in the context of Antidote)

It is not called "immutable interface" anywhere.

Regarding the database update and query DSL, a way to group together multiple key-updates into a single map update would be helpful. At the moment there is no way to issue a map-update that updates more than one key in the map.

I think changing this would require to change the API to be more similar to the API of the JavaScript client.
That could look something like this:

tx.execute(
        map(bucket, "my_map").update(
            counter("c").increment(),
            register("r").set("hello")
        )
);

or similarly (using a Builder):

map(bucket, "my_map")
  .update(counter("c").increment())
  .update(register("r").set("hello"))
  .removeKey(set("s"))
  .execute(tx)

Compared to the current API:

MapRef<String> my_map = bucket.map_rr("my_map");
my_map.counter("c").increment(tx);
my_map.register("r").set(tx, "hello");

Drawbacks of this approach:

• a bit harder to navigate in an IDE (less methods reachable by simple dot + autocomplete)
• it is easy to create an update and forget to execute it (this happened to some people using the JavaScript client, but in Java it might help to use the javax.annotation.CheckReturnValue annotation)
• simple updates are a bit more verbose, since an additional execute call is required
• it would be a completely different interface, so no backwards compatibility at all

Some benefits would be:

• It is possible to build more complex update-operations which update several entries in a map at once
• It is possible to extract map-keys with their type into variables (for example CounterRef c = counter("c");)
• Could reduce the use of generics and ValueCoder instances.

[peterzeller]

The updated interface is now available as version 0.1.0. I still don't consider this a stable API, so feedback is welcome ;)

[peterzeller]

Feedback from Nuno:

quick first comment: I found the names of the interfaces for crdts strange - IntegerKey

Maybe we should think about naming it AntidoteInteger, AntidoteSet, etc.