You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When building child parameter for specific nonabstract type io/evitadb/externalApi/graphql/api/catalog/dataApi/builder/constraint/GraphQLConstraintSchemaBuilder.java:228 (io.evitadb.externalApi.graphql.api.catalog.dataApi.builder.constraint.GraphQLConstraintSchemaBuilder#buildChildConstraintValue), it should not resolve child domain from property type as this neglects the custom domain from the parent child parameter, which is not neglected when a full container is build. This way, we cannot define custom domain for the inside of the child constraint. Instead, we should probably go deeper and somehow resolve domain for the parameters of the concrete constraint of the parent child parameter.
Specific example is the Segment constraint where we want to use OrderBy container with entity domain for its children, but in current implementation, the entity domain is converted to the generic domain of OrderBy constraint and the entity domain and its purpose to generate children for entity within OrderBy is lost:
The desired logic works for additional children, because there is no domain-from-property-type convertion, so maybe we should utilize something similar even for direct children.
Workaround for now is to not use specific class for generic containers for direct children, instead define its children directly:
Also, we should filter by domain even in these methods io.evitadb.api.query.descriptor.ConstraintDescriptorProvider#getConstraint* not only by class. However, this is dependent on the first issue.
The text was updated successfully, but these errors were encountered:
When building child parameter for specific nonabstract type
io/evitadb/externalApi/graphql/api/catalog/dataApi/builder/constraint/GraphQLConstraintSchemaBuilder.java:228
(io.evitadb.externalApi.graphql.api.catalog.dataApi.builder.constraint.GraphQLConstraintSchemaBuilder#buildChildConstraintValue
), it should not resolve child domain from property type as this neglects the custom domain from the parent child parameter, which is not neglected when a full container is build. This way, we cannot define custom domain for the inside of the child constraint. Instead, we should probably go deeper and somehow resolve domain for the parameters of the concrete constraint of the parent child parameter.Specific example is the
Segment
constraint where we want to useOrderBy
container with entity domain for its children, but in current implementation, the entity domain is converted to the generic domain ofOrderBy
constraint and the entity domain and its purpose to generate children for entity withinOrderBy
is lost:The desired logic works for additional children, because there is no domain-from-property-type convertion, so maybe we should utilize something similar even for direct children.
Workaround for now is to not use specific class for generic containers for direct children, instead define its children directly:
Also, we should filter by domain even in these methods
io.evitadb.api.query.descriptor.ConstraintDescriptorProvider#getConstraint*
not only by class. However, this is dependent on the first issue.The text was updated successfully, but these errors were encountered: