-
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
Rework sorting by multiple attributes #11
Comments
Removed `Multiple` type, added support for multiple arguments in `attributeNatural` ordering constraint.
In order to support multiple attribute names in order constraints we will not use classifiers for it, instead we use value annotation. But this way we cannot have 2 same constraints on the same level. Thus, we introduce array into orderBy with implicit container but unlike in filterBy where we use AND for it, here we just flat children into parent container. {
orderBy: [
{
"attributeCodenatural": DESC,
"attributeNatural": {}
},
{
"attributeNatural": {},
"entityproperty": {
}
}
]
} |
Removed `Multiple` type, added support for multiple arguments in `attributeNatural` ordering constraint.
…ish support for multiple creators with same name and different classifiers
We need to avoid and remove data type `Multiple`. Problem with this type is that it hides inner data types (which there may be multiple) and there is also problem how to describe this type to the end users. We need to stick to analogies to existing and well established data store - primarily SQL. On the other hand we need to allow both these scenarios: - sort by two or more attributes in "expected way" - i.e. secondary ordering decides order of elements when primary ordering cannot decide because values are the same - sort by two or more attributes when the sorting handles "NULLs" last scenario - i.e. there is no attribute found for primary attribute in an entity We also want to avoid situation where we would need to compare values of the entities in real-time. We already know it's slower than current masking process for pre-sorted arrays. This was the original reason why `Multiple` constraint exists in the first place. The proposed solution discussed with @lho is: - add support for creating multi-attribute sort indexes in EntitySchema / Reference schema by adding so called SortableAttributeCompounds which will aggregate sort direction for multiple existing attributes (which doesn't need necessarily to be sortable themselves) The final composition would like this: ``` attribute(nameOfCompound, DESC) ```
We should also relax on requiring that sortable reference attribute is present in entity only once, when multiple references are selected the sort order should be combined: - in case of hierarchy reference by a deep traversal order of the filter matching hierarchy tree - in case of plain referenced entities by a ascending order of their primary keys
…indexed` Indexed name much more captures the meaning of this property - it controls not only whether the reference is filterable, but also whether it is sortable.
I've added two additional TODOs for missing tests |
TODOs that were on me are done. |
Cool, tests are passing, we're finally done. |
…attributes #11 rework sorting by multiple attributes
…EST tests where are reference attributes
…EST tests where are reference attributes
According to the test results we observer a great reduction in throughput due to ordering. Introduced in #11
According to the test results we observer a great reduction in throughput due to ordering. Introduced in #11
According to the test results we observer a great reduction in throughput due to ordering. Introduced in #11
According to the test results we observer a great reduction in throughput due to ordering. Introduced in #11
We need to avoid and remove data type
Multiple
. Problem with this type is that it hides inner data types (which there may be multiple) and there is also problem how to describe this type to the end users. We need to stick to analogies to existing and well established data store - primarily SQL. On the other hand we need to allow both these scenarios:We also want to avoid situation where we would need to compare values of the entities in real-time. We already know it's slower than current masking process for pre-sorted arrays. This was the original reason why
Multiple
constraint exists in the first place.The proposed solution discussed with @lho is:
The final composition would like this:
The text was updated successfully, but these errors were encountered: