[API] Schemata containing simple types cannot be retrieved via the API
wwerner opened this issue · 6 comments
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.httpstarting fromL:148one 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
stringproperty, 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.
Findings so far:
- Returning
Completes.withFailure(Optional.empty())fromio.vlingo.schemata.query.SchemaVersionQueriesActor#resolvecauses the compiler to hang. ReturningwithSuccessleads 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/
CodeResourceit still hangs despite the change
@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.
@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.