Implement Storage for DynamoDB

[kmruiz]

WIP -> Solves issue #1

This is a basic implementation of a DynamoDB state store using the asynchronous DynamoDB client.

Notes

• I've added a CreateTableInterest when writing in case someone wants to create DynamoDB tables programmatically. However, using Cloudformation is the desired way.
• It uses the Asynchronous Client
• Tests are integration tests with a in-memory dynamodb to ensure that everything is working. This follows the current JDBC conventions for testing. Sadly this has some 'uncomfortable' requirements, like some sqlite dependencies and maven plugins (see pom.xml changes).
• It uses a table per each entity class. The table name is dynamic, using this format: vlingo_${FULL_QUALIFIED_CLASS_NAME_WITH_UNDERSCORES_INSTEAD_OF_DOTS}. There is an example on the test class.
• State.NullState implements State<Object>. Java generics are not covariant, so I can not use State.NullState as valid implementation of State<String>. I used null at this point, but it should be solved somehow.
• I didn't find a way to use Read/Write Interest to share the exception with the caller.

Current State

• [x] Write State to a DynamoDB Table
• [x] Read State from a DynamoDB Table
• [x] Handle errors when a record does not exist during a read operation
• [x] Handle errors when a table does not exist during a write operation
• [x] Handle errors when a table does not exist during a read operation
• [x] Notify CreateTableInterest when writing a record (as we need a table)
• [x] Implement a NoopCreateTableInterest
• [x] Handle versioning on writing
• [x] Change null in case of errors to State.NullState or some other state (maybe State.ErrorState?)
• [x] Save not confirmed dispatchables
• [x] Delete on confirmed dispatches
• [x] Query not confirmed dispatches

Please, give some feedback if you find any issues on the current implementation.

[VaughnVernon]

• Thanks! This is a great start. Here are some top-down comments.
• The pom... OMG :) For the other databases I only need a driver dependency. Makes me want it to be a separate package. Maybe this should be a documentation detail. Or is is required to run test? Is there any way to use a free AWS account via internet? (Maybe a bad idea, but trying to think minimalistic.)
• The DynamoDBTextStateActor must extend io.vlingo.actors.Actor in order to operate asynchronously. Instances must be created via World#actorFor() or Stage#actorFor(). Send messages via type-safe interface methods.
• Register entity/aggregate types to table/collection/bucket names using StateTypeStateStoreMap method stateTypeToStoreName() prior to using any given StateStore. The StateStore implementation uses StateTypeStateStoreMap method storeNameFrom() to get the table/collection/bucket name given a state.dataType parameter. See source code.
• Perhaps I am missing something, but each write must persist both the State and the Dispatchable state. I thought that's why you would use a BatchWriteItemRequest.
• Following a write() the State must be dispatched.
• This is all I am writing now as nothing else stands out at this time.

[kmruiz]

Hi Vaughn!

Actually DynamoDB dependencies are all of them but the SDK are for testing purpouses only :D :

• DynamoDBLocal is backed by a SQLite, so we need DLLs/SO to run it (without them it just crashes).
• DynamoDBLocal itself is binary-only, so it can not be published to Maven Central (they use their own repository in S3)

Surprisingly is quite fast to download everything.

I have several questions about how to implement the Dispatchable state persistence:

• ~I've seen in the code that the array of Dispatchables is not persisted, but saved in memory and then dispatched.~ EDIT: I've seen that in the JDBC state store they are persisted in a table.
• Dispatchables should be sent in order of arrival or order of persistence? Because DynamoDB API is asynchronous (there is also a sync API in case of necessity) I can not ensure that two calls to the API will end in order.
• Needs the persistence actor to implement DispatcherControl? Because if Dispatchables should be sent in persistence order, the actual dispatch should be done by the Async Handler.

And I have some 'convention' questions :D.

• How do I notify the caller that there was an error? I can not use NullState because of type safety, and I can not share the exception with the caller.
• In case of a handled exception where I don't have any solution (like reading from a non-existing table) what is the default convention for failing?
• What should I do if TypeVersion is different? Is there any way to call a migration on the state?

Thanks for your help!

[kmruiz]

I would say that, by now, I could considered it usable:

• Persists Dispatchables and are handled asynchronously by the actor (that implements DispatcherControl)
• Also saves the state on DynamoDB for each class (and registers the table name)

Is there anything left to ensure that is working?

[VaughnVernon]

@kmruiz I missed a few of your questions:

What should I do if TypeVersion is different? Is there any way to call a migration on the state?

Currently there is no specific migration tools and the differences are left to the application developer to work out the mappings. There will likely be additional tooling provided to help with this, but most of the heavy lifting will still rest on the developer's shoulders.

Needs the persistence actor to implement DispatcherControl?

Yes. The implementation must remove/delete the Dispatchable from storage when it receives confirmDispatched() and also arrange for all unconfirmed to be re-dispatched when dispatchUnconfirmed() is received.

• I notice that you consider the InMemory... implementations as somehow missing persistence features. You should think of InMemory... implementations as complete and the persistence of putting to a Map conceptually the same as disk persistence, including like JDBC and DynamoDB. In other words, think of InMemory... as the same as disk persistence.

Dispatchables should be sent in order of arrival or order of persistence?

I think it depends on the projection implementation, and thus you should offer the parameterized option to operate either sync or async. Still, the Dispatcher and Projection should not count on total ordering and/or exactly-once delivery because there could be redelivery caused by slow/failed confirmation, for example. So every kind of sensitive projection should be an idempotent receiver.

[kmruiz]

Hi! Sorry for the late answer!

I think there are three things left for considering this PR done (correct me if I'm wrong):

• Update to vlingo 0.2.8+
• Implement BinaryStore (can I use also Json serialization for the binary store?)
• Change NullState to provide also the error
• Add comments to pom.xml to separate dependencies by persistence

[VaughnVernon]

Yes, I agree, but just a few clarifications seem appropriate.

1. The idea of the BinaryStateStore is that you write and read byte[]. So you could serialize JSON to bytes, but it would be more like storing a Protobuf serialization. If you mean to use JSON as bytes just for testing, that's fine of course. Did I understand you correctly?

2. I have already changed NullState to parameterized NullState<T> and provided states:

public static NullState<byte[]> Binary = new NullState<>(EmptyBytesData); public static NullState<String> Text = new NullState<>(EmptyTextData);

I also added a method to the ReadResultInterest:

void readResultedIn(final Result result, final Exception cause, final String id, final State<T> state);

And also to WriteResultInterest:

void writeResultedIn(final Result result, final Exception cause, final String id, final State<T> state);

So now you can write code such as:

} catch (Exception e) {
  interest.writeResultedIn(Result.Error, e, state.id, state);
}

And like this:

if (storeName == null) {
  final String message = "No store mapping for " + type.getName();
  interest.readResultedIn(Result.NoTypeStore, new IllegalStateException(message), id, NullState.Binary);
}

Makes sense?

[kmruiz]

Makes totally sense, actually was the exact part that I was missing for Read/WriteResultInterest. About using Protobuf for the BinaryStore, I think it's a good idea, I can implement it :D.

Thanks for your help!

[VaughnVernon]

Excellent, thanks! Also you had some comments about adapting/migrating from one data version to the next. I have some experience with that, and also some ideas. Still, I would like to know what your ideas are, so please share what you have in mind.

[kmruiz]

Hi!

I've been looking at the documentation of Protocol Buffers:

https://developers.google.com/protocol-buffers/docs/javatutorial

And seems that you need to generate code to make it work and it highly depends on the class that you want to persist. It will generate a class, builders and some serialization code.

I was thinking maybe it's a better idea to use something like MessagePack:

https://msgpack.org/index.html

It's tiny and easy to parse. What do you think?

This is the only thing left to merge this PR.

And about migrations, it's a big topic :D and it doesn't affect only DynamoDB but all persistences, maybe we can create an issue and discuss it there. What do you think?

[VaughnVernon]

All good, thanks!

Regarding binary store testing, you don't need Protobuf or MessagePack. I thought you were in need of using a reliable binary serialization tool for a project using vlingo-symbio. For testing it's much easier.

You can just convert a String to byte[] as is done here. After you write and then read, you can assert the binary read state against the write state.

When you are ready for merge please comment and I can then merge your work.

[kmruiz]

When the build is confirmed to be green, it's ready to be merged :D.

[kmruiz]

Seems that the InMemoryPersistence test somehow had a timeout. I'm going to push an empty commit to run the build again.

[VaughnVernon]

@kmruiz You can navigate here and restart the build.

[kmruiz]

Good to know! I didn't see the option :D! Now everything is green!

[VaughnVernon]

@kmruiz Are you ready for a merge or would you prefer doing more work on the binary store before the merge?

[kmruiz]

@VaughnVernon IMHO it can be merged, I would like to refactor the implementation of record adapters, to reuse more code, but it's a safe refactor that can be done later.