Curently the ObjectStore protocol defines a method used to register mapping for a given persistent type.

void registerMapper(final PersistentObjectMapper mapper);

Most of the stores simply proxy the call to their persistent delegates and do nothing more.
With the introduction of io.vlingo.symbio.store.dispatch.Dispatchable the store has to have the mapping for it. Also a copy of the store delegate is usually used by DispatcherControlActor actor. More details in this discussion: vlingo/xoom-symbio-jdbc#14 (comment)

It makes more sense to register the mapping directly with the persistent delegate.
The idea is to create an interface, for example ObjectStoreDelegate that defines the registerMapper implementation.

This will allow the clients to register all the necessary mappings, including the one for io.vlingo.symbio.store.dispatch.Dispatchable before creating the actor.

With the new Object store delegate interface, the following projects must also be changed:

• https://github.com/vlingo/vlingo-symbio-geode
• https://github.com/vlingo/vlingo-symbio-jdbc
• https://github.com/vlingo/vlingo-lattice (mostly tests)

I stumbled upon this issue while upgrading from vlingo 1.3.0 to 1.4.0.

Since vlingo/xoom-symbio-jdbc#43, the Journal factory no longer works:

Journal.using(stage, JDBCJournalActor.class, dispatcher, configuration);

The implementation assumes that dispatcher is part of argument list:

static <A extends Actor, T, RS extends State<?>> Journal<T> using(final Stage stage, final Class<A> implementor,
          final Dispatcher<Dispatchable<Entry<T>,RS>> dispatcher, final Object...additional) {
    return additional.length == 0 ?
             stage.actorFor(Journal.class, implementor, dispatcher) :
             stage.actorFor(Journal.class, implementor, dispatcher, additional);
  }

While it is still valid for some implementations (like InMemoryJournalActor) it is no longer the case for JDBCJournalActor.

/cc @pflueras

Hello!

I created this issue just to give you tracking about the implementation of the DynamoDB storage delegate. Suggestions are welcome because it will be my first contribution to vlingo!

Assumptions:

• I need to write an Actor that implements TextStateStore (as in the JDBCTextStateStoreActor)
• Interests are like promises

Questions:

• What is the dispatcher doing actually? Where can I find some documentation? Do I need to implement it also in my TextStateStore?

Thanks for your time!

Currently the State::metadata()::object() may or may not be available. The current contract is to check for null. Implement the means to check for presence/absence using Optional.

I migrated a very small PoC to vlingo-symbio to see how it works. I looked into vlingo-schemata for the setup. It works so far but I noticed a few things:

• vlingo-symbio needs some 'ceremonial' code to register EntryAdapter (e.g. see https://github.com/vlingo/vlingo-schemata/blob/master/src/main/java/io/vlingo/schemata/infra/persistence/EntryAdapters.java)
  -- all the EntryAdapters are looking equal, so maybe it would be an option to have a factory in SourceTypeRegistry that could generate default EntryAdapters if not custom was found
  -- all EntryAdapters needs to be registered twice. Once in the in the Journal and once in the SourceTypeRegistry. This is somehow error prone, and won't be necessary if the journal would use the SourceTypeRegistry
  Somehow the generics do not work for me:
  -- SourcedTypeRegistry.Info<T> just works as you leave out the type parameter (see https://github.com/vlingo/vlingo-schemata/blob/master/src/main/java/io/vlingo/schemata/infra/persistence/EntryAdapters.java again). This is because Info expects a Journal<T> and a Class<Sourced<T>> as parameter. If using Journal<String> like for the Postgres journal, the Sourced actor needs to be Sourced<String> too. But that does not work, as EventSourced is Sourced<DomainEvent> ...
• maybe just the signature of Info needs to be fixed e.g. to Info(final Journal<T> journal, final Class<Sourced<DomainEvent>> sourcedType, final String sourcedName)
  -- Every quick fix I could imagine would not work (e.g. to make PostgresJournal an Journal<DomainEvent>)
• I'm not sure if this is the same for all other journal implementations, but Entry has an id property, that is used nowhere. This is somehow confusing.

Adapters do more than just serialize and deserialize, but at the beginning in most cases you don't need these extra functions as your events have version 1 and upcasting, etc., is not necessary. Therefore, you could have a factory that could be either overridden to create customized Adapters or the factory just comes into play if no custom adapter has been registered.

The DynamoDB implementation is very heavyweight because its use requires the download of the local test environment dependencies for DynamoDB. On a non-optimal network that I had to use recently it required approximately 3 hours to get all the dependencies. (It's attributed to how Amazon has packaged the dependencies, which requires downloading all revisions and patches to the Java API that ever existed.) Although not a fault of the author/contributor, this is unacceptable and will hamstring adoption of vlingo-symbio for those not interested in a DynamoDB implementation. Moving this outside the vlingo-symbio core also sets a precedent for how other implementations will/can be provided.

-- @kmruiz Please move the DynamoDB support to vlingo-symbio-dynamodb
-- I will move the JDBC support to vlingo-symbio-jdbc