3.7 Sorted Output

This special field sets sorting criteria for the records contained in a record set. Its usage is:

     %sort: field1 field2 ...

Meaning that the desired order for the records will be determined by the contents of the fields named in the %sort value. The sorting is always done in ascending order, and there may be records that lack the involved fields, i.e. the sorting fields need not be mandatory.

It is an error to have more than one %sort field in the same record descriptor, as only one field list can be used as sorting criteria.

Consider for example that we want to keep the records in our inventory system ordered by entry date. We could achieve that by using the following record descriptor in the database:

     %rec: Item
     %type: Date date
     %sort: Date
     
     Id: 1
     Title: Staplers
     Date: 10 February 2011
     
     Id: 2
     Title: Ruler Pack 20
     Date: 2 March 2009
     
     ...

As you can see in the example above, the fact we use %sort in a database does not mean that the database will be always physically ordered. Unsorted record sets are not a data integrity problem, and thus the diagnosis tools must not declare a recfile as +invalid because of this. The utility recfix provides a way +to physically order the fields in the file (see Invoking recfix).

On the other hand any program listing, presenting or processing data extracted from the recfile must honor the %sort entry. For example, when using the following recsel program in the database above we would get the output sorted by date:

     $ recsel inventory.rec
     Id: 2
     Title: Ruler Pack 20
     Date: 2 March 2009
     
     Id: 1
     Title: Staplers
     Date: 10 February 2011

The sorting of the selected field depends on its type:

• Numeric fields (integers, ranges, reals) are numerically ordered.
• Boolean fields are ordered considering that “false” values come first.
• Dates are ordered chronologically.
• Any other kind of field is ordered using a lexicographic order.

It is possible to specify several fields as the sorting criteria. In that case the records are sorted using a lexicographic order. Consider for example the following unsorted database containing marks for several students:

     %rec: Marks
     %type: Class enum A B C
     %type: Score real
     
     Name: Mr. One
     Class: C
     Score: 6.8
     
     Name: Mr. Two
     Class: A
     Score: 6.8
     
     Name: Mr. Three
     Class: B
     Score: 9.2
     
     Name: Mr. Four
     Class: A
     Score: 2.1
     
     Name: Mr. Five
     Class: C
     Score: 4

If we wanted to sort it by Class and by Score we would insert a %sort special field in the descriptor, having:

     %rec: Marks
     %type: Class enum A B C
     %type: Score real
     %sort: Class Score
     
     Name: Mr. Four
     Class: A
     Score: 2.1
     
     Name: Mr. Two
     Class: A
     Score: 6.8
     
     Name: Mr. Three
     Class: B
     Score: 9.2
     
     Name: Mr. Five
     Class: C
     Score: 4
     
     Name: Mr. One
     Class: C
     Score: 6.8

The order of the fields in the %sort field is significant. If we reverse the order in the example above then we get a different sorted set:

     %rec: Marks
     %type: Class enum A B C
     %type: Score real
     %sort: Score Class
     
     Name: Mr. Four
     Class: A
     Score: 2.1
     
     Name: Mr. Five
     Class: C
     Score: 4
     
     Name: Mr. Two
     Class: A
     Score: 6.8
     
     Name: Mr. One
     Class: C
     Score: 6.8
     
     Name: Mr. Three
     Class: B
     Score: 9.2

In this last case, Mr. One comes after Mr. Two because the class A comes before the class B even though the score is the same (6.8).