-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(map): Resolve namespace resolution for Map Types #9
Conversation
Signed-off-by: Jonathan Casey <[email protected]>
Signed-off-by: Jonathan Casey <[email protected]>
Signed-off-by: Jonathan Casey <[email protected]>
bacbf59
to
595838c
Compare
Signed-off-by: Jonathan Casey <[email protected]>
lib/metamodelutil.js
Outdated
const nameK = metaModel.key.$class === `${MetaModelNamespace}.ObjectMapKeyType` ? metaModel.key.type.name : ModelUtil.getShortName(metaModel.key.$class); | ||
metaModel.key.$class === `${MetaModelNamespace}.ObjectMapKeyType` ? metaModel.key.type.namespace = resolveName(nameK, table) : metaModel.key.namespace = resolveName(nameK, table); | ||
const nameV = metaModel.value.$class === `${MetaModelNamespace}.ObjectMapValueType` ? metaModel.value.type.name : ModelUtil.getShortName(metaModel.value.$class); | ||
metaModel.key.$class === `${MetaModelNamespace}.ObjectMapKeyType` ? metaModel.value.type.namespace = resolveName(nameV, table) : metaModel.value.namespace = resolveName(nameV, table); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit, please refactor this to have a branch for ObjectMapKeyType and an else case. This will make this easier to read and DRY the repeated tenary operators.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should have a new case for MapDeclaration
which calls resolveTypeNames
on both key
and value
(recursion).
There should then be cases for ObjectMapKeyType
and ObjectMapValueType
that follows the established pattern:
const name = metaModel.type.name;
metaModel.type.namespace = resolveName(name, table);
(metaModel.decorators || []).forEach((decorator) => {
resolveTypeNames(decorator, table);
});
A good test-case to add would be:
namespace A
scalar MyScalar extends String
namespace B
map EventMap {
o MyScalar
o Event // requires implicit resolution using `concerto` namespace
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like we may also have a bug here with ScalarDeclaration
missing? Can you test and create an issue for that please?
lib/metamodelutil.js
Outdated
@@ -64,6 +65,14 @@ function createNameTable(priorModels, metaModel) { | |||
'Participant': concertoNs, | |||
'Transaction ': concertoNs, | |||
'Event': concertoNs, | |||
'StringMapKeyType': concertoNs, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure I understand this. StringMapKeyType is not defined in the [email protected]
namespace - that is a type from the metamodel. What are we trying to do here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The intention is that any type used within a map context should have its namespace resolved.
I guess my question is - why differentiate between types on the metamodel vs those on the root model when resolving namespace - why should namespace apply to only root types, but not in the case of primitives? The metamodel is versioned, after all.
If I think about this from the point of view that a primitive type will always be a primitive type it doesn't really make sense to version it to a namespace, and in that case there is no need to generate namespace values for primitives in the context of a resolve
command output.
Feels like I may not be seeing the forest for the trees.., it would be useful if you can share a scenario under which the resolve function is necessary, from a client perspective.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What the createNameTable
code is doing (before you changes) is saying that anywhere we see the unqualified type Event
being used (et al) it should be resolved as [email protected]
.
The concerto
namespace is special in that it is managed by the ModelManager
implicitly. I.e. any model file can use Event
without having to import it. Here is the code that adds the concerto
namespace to the model manager on construction.
https://github.com/accordproject/concerto/blob/main/packages/concerto-core/lib/basemodelmanager.js#L126
Your code change is saying that StringMapKeyType
is also defined in the concerto
namespace, which is not correct.
I don't think you need to update the logic in createNameTable
- it uses the imported types to build the name resolution table (resolving from a short type name to a namespace). Given that maps must import their types to use them as keys or values this should just work...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The "resolution" process takes an AST with imports and unqualified type names and uses the imports to set the namespace
property on all the TypeIdentifier nodes. In effect it is an optimisation that makes it easier for consumers of the AST: they no longer need to do the (somewhat complex) import resolution logic.
lib/metamodelutil.js
Outdated
const nameK = metaModel.key.$class === `${MetaModelNamespace}.ObjectMapKeyType` ? metaModel.key.type.name : ModelUtil.getShortName(metaModel.key.$class); | ||
metaModel.key.$class === `${MetaModelNamespace}.ObjectMapKeyType` ? metaModel.key.type.namespace = resolveName(nameK, table) : metaModel.key.namespace = resolveName(nameK, table); | ||
const nameV = metaModel.value.$class === `${MetaModelNamespace}.ObjectMapValueType` ? metaModel.value.type.name : ModelUtil.getShortName(metaModel.value.$class); | ||
metaModel.key.$class === `${MetaModelNamespace}.ObjectMapKeyType` ? metaModel.value.type.namespace = resolveName(nameV, table) : metaModel.value.namespace = resolveName(nameV, table); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should have a new case for MapDeclaration
which calls resolveTypeNames
on both key
and value
(recursion).
There should then be cases for ObjectMapKeyType
and ObjectMapValueType
that follows the established pattern:
const name = metaModel.type.name;
metaModel.type.namespace = resolveName(name, table);
(metaModel.decorators || []).forEach((decorator) => {
resolveTypeNames(decorator, table);
});
A good test-case to add would be:
namespace A
scalar MyScalar extends String
namespace B
map EventMap {
o MyScalar
o Event // requires implicit resolution using `concerto` namespace
}
lib/metamodelutil.js
Outdated
const nameK = metaModel.key.$class === `${MetaModelNamespace}.ObjectMapKeyType` ? metaModel.key.type.name : ModelUtil.getShortName(metaModel.key.$class); | ||
metaModel.key.$class === `${MetaModelNamespace}.ObjectMapKeyType` ? metaModel.key.type.namespace = resolveName(nameK, table) : metaModel.key.namespace = resolveName(nameK, table); | ||
const nameV = metaModel.value.$class === `${MetaModelNamespace}.ObjectMapValueType` ? metaModel.value.type.name : ModelUtil.getShortName(metaModel.value.$class); | ||
metaModel.key.$class === `${MetaModelNamespace}.ObjectMapKeyType` ? metaModel.value.type.namespace = resolveName(nameV, table) : metaModel.value.namespace = resolveName(nameV, table); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like we may also have a bug here with ScalarDeclaration
missing? Can you test and create an issue for that please?
Signed-off-by: Jonathan Casey <[email protected]>
Pull Request Test Coverage Report for Build 6588566313
💛 - Coveralls |
Signed-off-by: Jonathan Casey <[email protected]>
Signed-off-by: Jonathan Casey <[email protected]>
Signed-off-by: Jonathan Casey <[email protected]>
Signed-off-by: Jonathan Casey <[email protected]>
Signed-off-by: Jonathan Casey <[email protected]>
Signed-off-by: Jonathan Casey <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Description
Handle MapDeclaration cases for the
resolve
command.Author Checklist
--signoff
option of git commit.