RawForeignValueToObjectConverter now create a single query with a OR of all criteria for properties that end you loading instances of a certain type/ObjectDescriptor. The first handling of dataOrderings to resolve a property with the content ordered according to a property dataOrderings relies on the the in-memory sorting of what is returned. Since we already loop on the results to re-assign the results to the corresponding promises of individual objects, we rely on the fact that the relative order should be maintained by the in-memory sorting, but that won't work always.
What we need to do is issue a different query for each different dataOrdering, get the raw data service (PostgreSQL here) to add the sorting at the source, and add a way to specify in the results that the data was actually sorted, so the client can avoid doing it again in that case. The challenge is to keep down the number of messages. But since we support serializing an array, that should be fine, the results might be combined. The challenge might be for the RawDataService to have enough info to do just one round trip, in processing an array, the read operations are distributed individually in the DataWorker, and therefore wouldn't be easy to re-combine as such.
RawForeignValueToObjectConverter now create a single query with a OR of all criteria for properties that end you loading instances of a certain type/ObjectDescriptor. The first handling of dataOrderings to resolve a property with the content ordered according to a property dataOrderings relies on the the in-memory sorting of what is returned. Since we already loop on the results to re-assign the results to the corresponding promises of individual objects, we rely on the fact that the relative order should be maintained by the in-memory sorting, but that won't work always.
What we need to do is issue a different query for each different dataOrdering, get the raw data service (PostgreSQL here) to add the sorting at the source, and add a way to specify in the results that the data was actually sorted, so the client can avoid doing it again in that case. The challenge is to keep down the number of messages. But since we support serializing an array, that should be fine, the results might be combined. The challenge might be for the RawDataService to have enough info to do just one round trip, in processing an array, the read operations are distributed individually in the DataWorker, and therefore wouldn't be easy to re-combine as such.