Aggregation in this case means two different things: sorting and removing shadowed users.
Both of these have problems if you try to do them directly in the DB.
Removing shadowed users I believe is too complex for direct DB manipulation and sorting could produce different results to today based on the collation.
Furthermore some DAO implementations (JIRA) include in memory caches, so directly calling the DB would lead to a massive decrease in performance.
Instead there are other inefficiencies that we could explore:
- ApplicationServiceGeneric lowercases the usernames for duplicate detection
We already store the lowercase name in the DB but we don't expose it through the User object
- ApplicationServiceGeneric sorts Users even when there are is no "maxResults" in the query
Sorting is only needed when paging.
An ALL_RESULTS query is going to be big and is most in need of optimisation.
- ApplicationServiceGeneric sorts all Users
We only need to sort up to the end of the current page.
Users that don't fall into that subset can be discarded without full sorting
Suggestion
Justin Koke
made changes -
Aggregation in this case means two different things: sorting and removing shadowed users.
Both of these have problems if you try to do them directly in the DB.
Removing shadowed users I believe is too complex for direct DB manipulation and sorting could produce different results to today based on the collation.
Furthermore some DAO implementations (JIRA) include in memory caches, so directly calling the DB would lead to a massive decrease in performance.
Instead there are other inefficiencies that we could explore:
We already store the lowercase name in the DB but we don't expose it through the User object
Sorting is only needed when paging.
An ALL_RESULTS query is going to be big and is most in need of optimisation.
We only need to sort up to the end of the current page.
Users that don't fall into that subset can be discarded without full sorting