RocksDB current state WIP: #97

[jspenger]

I created a temporary branch: https://github.com/portals-project/portals/tree/rocksdb-experiment to which we can push temporary work, if necessary.

[jspenger]

Outstanding tasks:

• [ ] There should be no errors except for serialization errors. The error above (1) should be fixed before being pushed/merged.
• [ ] Implement the remaining tasks for #96 . I think the issues here are a small-enough size to bunch all of them into the same PR.
• [ ] Don't forget to format and cleanup the code.

[jspenger]

For the Config issue, it should also be possible to programmatically modify the config, and pass it explicitly to the system factory like the following Akka examples: https://doc.akka.io/docs/akka/current/general/configuration.html#configuring-multiple-actorsystem. This is especially to simplify things with automatic testing.

[MKLepium]

For the Config issue, it should also be possible to programmatically modify the config, and pass it explicitly to the system factory like the following Akka examples: https://doc.akka.io/docs/akka/current/general/configuration.html#configuring-multiple-actorsystem. This is especially to simplify things with automatic testing.

The current attempt builds/reads the config on the go during the runtime of the application. Akka on the other hand does it by giving the configuration upon start to the application. From the mentioned documentation:

val complete = ConfigFactory.load(combined);  
// create ActorSystem  
val system = ActorSystem(rootBehavior, "myname", complete);

Should we consider doing that with our implementation aswell or shall we proceed with the current way of implementation?

[jspenger]

It is necessary to be able to modify the config from the code for automated testing purposes, for example in order to test both state backends.

Supplying a custom config should be optional (same as in Akka, etc.):

Systems.interpreter()
Systems.interpreter(config)

Additionally, above I asked

Perhaps, find some suitable selection, and then we can discuss this selection.

We can go with the typesafe config for now, just implement it in a way so that we could swap it later without too much effort if we think it is necessary (for example due to potential ScalaJS compatibility issues)

[jspenger]

Closed the PR as it was growing to an unwieldy size.