Closed wwerner closed 4 years ago
Findings so far:
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-63f78f88857d87d78544dee8ca614748R75CodeResource
it still hangs despite the changeThis issue seems to be a duplicate of https://github.com/vlingo/vlingo-schemata/issues/89
PR: https://github.com/vlingo/vlingo-schemata/pull/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.
@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 https://github.com/vlingo/vlingo-schemata/pull/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.
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 https://github.com/vlingo/vlingo-schemata/pull/115
This issue is likely to be fixed fixed by https://github.com/vlingo/vlingo-schemata/pull/117
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 theTypeResolver
inSchemaVersionQueriesActor
,CacheTypeResolver
did work with basic types.When compiling the same schema within a test, the compilation works.
To reproduce via the http API:
src/test/resources/rest-api-calls.http
starting fromL:148
one after anotherL:160
) leads to the issueTo reproduce via the UI:
string
property, see exampleSource
Minimal example spec:
There already was a discussion on Slack, but I prefer having an issue to reference instead of searching within the chat history.