letās say we have a schemaā¦
type Property {
label: String
description: String
variants: [PropertyVariant!]
}
type PropertyVariant @embedded {
status: String
configuration: String
price: Int
area: Int
}
Now let us say we have the following property (with 3 variants)
{
label: "Some label"
description: "Some description...."
variants: [
{
status: "Ready"
configuration: "1"
price: 100
area: 100
},
{
status: "Ongoing"
configuration: "2"
price: 200
area: 200
},
{
status: "Sold"
configuration: "3"
price: 300
area: 300
}
]
}
Now, let us suppose that I want to get hold of a property which has a variant that needs to satisfy multiple conditions, that becomes a problem. For example, letās say I am looking for a configuration of 3 which is not sold, with an area less than equal to 200. Second
According to stackoverflow, to query over multiple condition, requires multiple indexes. So letās create multiple indexes. With the terms set asā¦
data.variants.status
data.variants.configuration
data.variants.price
And automatically I can see that the Intersect(Join(Match))
method is not going to work. It is going to return this document even if this document does not have a variant that satisfy the condition.
I have suspicion that if I could store an object (the individual variants) in the index itself along with the property ref, i could use the index in conjunction with a udf as a custom resolver, to return the property correctly. But itās difficult for me to visualize exactly how this will work without seeing it in front of my eyes.
^^Use case ends here. Actual problem follows below
The obvious alternative, of course, is to create a separate collection for the variants, but for some reason, the graphql endpoint is not processing that correctly.
If I
- remove the @embedded directive.
- add a āproperty: Property!ā field to the variant schema definition
it creates the new āvariantsā collection, which is ok. It creates the necessary index for the one-to-many-relationship, which is ok. But for some reason, the generated schema does not have the new āpropertyā field in it. And when I add a new property with variants, these variants are inlined in the property document in the property collection, exactly as before, instead of having separate documents in the āvariantsā collection