[API] Schemata containing simple types cannot be retrieved via the API

[wwerner]

When requesting the sources for a schema that contains at least one basic type not checked for in io.vlingo.schemata.codegen.processor.types.ComputableTypeProcessor#resolveType, the request hangs.
Schema not containing simple types can be retrieved, but after trying to retrieve one that does, a second try with a schema that worked before also fails.
If I'm not mistaken, this only happens with the TypeResolver in SchemaVersionQueriesActor, CacheTypeResolver did work with basic types.

When compiling the same schema within a test, the compilation works.

To reproduce via the http API:

• Run all requests in src/test/resources/rest-api-calls.http starting from L:148 one after another
• The last request (L:160) leads to the issue

To reproduce via the UI:

• Open the UI
• Create Org/Unit/Context/Schema/SchemaVersion
• Use a specifciation containing a string property, see example
• Navigate to the schema version in the treeview
• Select the version
• Request the generated sources by clicking Source

Minimal example spec:

event Foo {
    string bar
}

There already was a discussion on Slack, but I prefer having an issue to reference instead of searching within the chat history.

[wwerner]

Findings so far:

• Returning Completes.withFailure(Optional.empty()) from io.vlingo.schemata.query.SchemaVersionQueriesActor#resolve causes the compiler to hang. Returning withSuccess leads to correct compilation; see https://github.com/vlingo/vlingo-schemata/pull/101/files#diff-cd6e0df9963281081f22c593e116d3fcR158 and https://github.com/vlingo/vlingo-schemata/pull/101/files#diff-63f78f88857d87d78544dee8ca614748R75
• When calling it via the UI/CodeResource it still hangs despite the change

[pflueras]

This issue seems to be a duplicate of #89
PR: #106 fixed only happy use cases (already in master).
Still to be fixed use cases when it is requested source code for non-existing SchemaVersion.
@wwerner please confirm that 'Source' button works correctly now.

[wwerner]

@pflueras Thanks, it does not hang anymore, thats certainly an improvement.

However, simple types other than event, version and timestamp are being ignored in the generated sources now.
See src/test/resources/io/vlingo/schemata/codegen/vss/allSingleTypes.vss for an example containing all possible simple types.

To reproduce, please have a look at #101, it contains both unit and e2e tests showing the issue.

In io.vlingo.schemata.codegen.specs.JavaCodeGenTests#testThatGeneratesABasicTypeWithAllConsideredInnerTypes, the code is compiled using the java backend directly which works.

In io.vlingo.schemata.codegen.JavaCodeGenSchemaVersionResolverTests#testThatSpecificationsContainingBasicTypesCanBeCompiledWithSchemaVersionQueryTypeResolver, the basic types are omitted in the generated sources as shown in the screen shot.

Please feel free to work in the feature/98-fix_compilation_w_basic_types (it is updated w/ the current state containing your fixes from master) branch directly so you don't have to merge the tests back and forth.

[VaughnVernon]

@wwerner My intention was for the typeVersion to be an int since io.vlingo.common.version. SemanticVersion understands how to convert into and out of multiple values of major, minor, and patch, as well as String representation. The int is only 4 bytes or less and as a JSON String-ified value most times 5-7 bytes (1.0.0 or 10.1.1, etc., and maybe 7 bytes as in 10.35.2).

Spec:
version typeVersion

becomes:
public final int typeVersion;

The above supports plain types, in case standard types not desired/used.

Further, if using a standard base class, spec should be:
extends io.vlingo.lattice.model.DomainEvent
extends io.vlingo.lattice.model.Command

becomes:
import io.vlingo.lattice.model.DomainEvent;
or:
import io.vlingo.lattice.model.Command;

public final class FooHappened extends DomainEvent {
// or
public final class DoFoo extends Command {

  // nothing here for version because standard types have:
  // public final int sourceTypeVersion;
  // and also no occurredOn here because standard types have:
  // public final long dateTimeSourced;
}

Sorry for the surprise extends. I have thought of how to deal with this but didn't finalize my ideas and this situation reminded me that it's necessary.

[wwerner]

This is not fixed yet. I opened a new branch containing tests to reproduce, as the original one was merged already. I ignore the failing tests on master now and work on the issue in #115

[pflueras]

This issue is likely to be fixed fixed by #117