[
https://issues.apache.org/jira/browse/JAMES-3374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nguyễn Việt Đức updated JAMES-3374:
-----------------------------------
Description:
# Why
For data sets where the total amount of data is expected to be very small,
clients can just fetch the complete set of data and then do any
sorting/filtering locally. However, for large data sets (e.g.,multi-gigabyte
mailboxes), the client needs to be able to search/sort/window the data type on
the server.
A query on the set of Foos in an account is made by calling "Foo/query".
This takes a number of arguments to determine which records to include, how
they should be sorted, and which part of the result should be returned (the
full list may be *very* long). The result is returned as a list of Foo ids.
# HOW
- Implement follow [RFC-8620][https://tools.ietf.org/html/rfc8620#section-5.5]
{code}
# DOD
- write an integration test demonstrating that the user can query/filter in
both ascending and descending order.
was:
# Why
With the new specification,
The following value for the property field on the Comparator object MUST be
supported for sorting:
receivedAt - The receivedAt date as returned in the Email object.
As an user, i want to be able to sort my emails by reception date.
# HOW
- Implement the sort field for the 'ReceivedAt' property in the query method
without handling the collation field
the sort field is defined like this :
{code:java}
sort: Comparator[]|null Lists the names of properties to compare between two
Foo records, and how to compare them, to determine which comes first in the
sort. If two Foo records have an identical value for the first comparator, the
next comparator will be considered, and so on. If all comparators are the same
(this includes the case where an empty array or null is given as the sort
argument), the sort order is server dependent, but it MUST be stable between
calls to Foo/query.
A Comparator has the following properties:
property: String The name of the property on the Foo objects to compare.
isAscending: Boolean (optional; default: true) If true, sort in ascending
order. If false, reverse the comparator’s results to sort in descending order.
collation: String (optional; default is server dependent) The identifier,
as registered in the collation registry defined in [@!RFC4790], for the
algorithm to use when comparing the order of strings. The algorithms the server
supports are advertised in the capabilities object returned with the Session
object (see Section 2).
If omitted, the default algorithm is server-dependent, but:
It MUST be unicode-aware.
It MAY be selected based on an Accept-Language header in the request
(as defined in [@!RFC7231], Section 5.3.5), or out-of-band information about
the user’s language/locale.
It SHOULD be case insensitive where such a concept makes sense for a
language/locale. Where the user’s language is unknown, it is RECOMMENDED to
follow the advice in Section 5.2.3 of [@!RFC8264].
The “i;unicode-casemap” collation [@!RFC5051] and the Unicode Collation
Algorithm (http://www.unicode.org/reports/tr10/) are two examples that fulfil
these criterion and provide reasonable behaviour for a large number of
languages.
When the property being compared is not a string, the collation property is
ignored, and the following comparison rules apply based on the type. In
ascending order:
Boolean: false comes before true.
Number: A lower number comes before a higher number.
Date/UTCDate: The earlier date comes first.
The Comparator object may also have additional properties as required for
specific sort operations defined in a type’s /query method.
{code}
# DOD
- write an integration test demonstrating that the user can filter by
receivedAt in both ascending and descending order.
> Email/query Support sort by ReceivedAt
> --------------------------------------
>
> Key: JAMES-3374
> URL: https://issues.apache.org/jira/browse/JAMES-3374
> Project: James Server
> Issue Type: Improvement
> Reporter: Nguyễn Việt Đức
> Priority: Major
>
> # Why
> For data sets where the total amount of data is expected to be very small,
> clients can just fetch the complete set of data and then do any
> sorting/filtering locally. However, for large data sets (e.g.,multi-gigabyte
> mailboxes), the client needs to be able to search/sort/window the data type
> on the server.
> A query on the set of Foos in an account is made by calling "Foo/query".
> This takes a number of arguments to determine which records to include, how
> they should be sorted, and which part of the result should be returned (the
> full list may be *very* long). The result is returned as a list of Foo ids.
>
> # HOW
> - Implement follow
> [RFC-8620][https://tools.ietf.org/html/rfc8620#section-5.5]
> {code}
> # DOD
> - write an integration test demonstrating that the user can query/filter in
> both ascending and descending order.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
