Issue 49629 - Sort table by numeric key fails
Summary: Sort table by numeric key fails
Status: CLOSED FIXED
Alias: None
Product: Writer
Classification: Application
Component: ui (show other issues)
Version: 680m95
Hardware: PC All
: P3 Trivial with 2 votes (vote)
Target Milestone: ---
Assignee: michael.ruess
QA Contact: issues@sw
URL:
Keywords:
: 68769 72345 (view as issue list)
Depends on:
Blocks: 60681
  Show dependency tree
 
Reported: 2005-05-21 02:37 UTC by Joe Smith
Modified: 2013-08-07 14:42 UTC (History)
1 user (show)

See Also:
Issue Type: PATCH
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
Sample document showing incorrect Table > Sort (8.13 KB, application/vnd.oasis.opendocument.text)
2005-05-21 02:40 UTC, Joe Smith
no flags Details
patch (848 bytes, patch)
2006-08-18 15:21 UTC, mmeeks
no flags Details | Diff
fixed patch - handles numeric/date formatting etc. (960 bytes, patch)
2006-08-18 20:55 UTC, mmeeks
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description Joe Smith 2005-05-21 02:37:20 UTC
Applying Table > Sort to a table contining numeric data does not sort the rows
properly, even specifying a "Numeric" sort key.  If the cells in the key column
are changed to "Number" format, then the sorting is done properly.

Expected result:
If a "Numeric" sort key is specified, the sort algorithm should try reasonably
hard to interpret the data as numbers, regardless of the cell format.  E.g., use
the leftmost group of digits.  In my actual table, I have data such as "9*",
which ought to sort between 8 and 10, regardless of the trailing asterisk.
Comment 1 Joe Smith 2005-05-21 02:40:13 UTC
Created attachment 26391 [details]
Sample document showing incorrect Table > Sort
Comment 2 Joe Smith 2005-05-21 02:56:00 UTC
Oops, I'm not sure the comments in the sample document are perfectly accurate --
I may have done something different as I was testing different sort keys.  The
problem should be simple to reproduce even if the results in the table are not
exactly as described.

<Joe
Comment 3 michael.ruess 2005-05-25 15:48:37 UTC
MRU->OS: since the number recognition is not active by default anymore, this has
got more importance IMO than before.
Digits in table cells shouldn't really be interpreted as strings anymore, when
the key type in sorting dialog is "numeric". This should be independent from the
selected number format.
Comment 4 michael.ruess 2006-08-18 14:50:08 UTC
*** Issue 68769 has been marked as a duplicate of this issue. ***
Comment 5 michael.ruess 2006-08-18 15:04:55 UTC
*** Issue 68769 has been marked as a duplicate of this issue. ***
Comment 6 michael.ruess 2006-08-18 15:14:08 UTC
MRU->OS: mmeeks has attached a patch proposal to issue 68769.
Comment 7 mmeeks 2006-08-18 15:21:44 UTC
Created attachment 38627 [details]
patch
Comment 8 mmeeks 2006-08-18 15:27:50 UTC
re-attach the patch. Which (incidentally) works fine with numeric formatting as
well ;-) [ but of course, quite possibly won't work with eg. Date formatting -
so we need a special case for that - clearly ].

Changing type to patch etc.
Comment 9 mmeeks 2006-08-18 20:55:10 UTC
Created attachment 38641 [details]
fixed patch - handles numeric/date formatting etc.
Comment 10 mmeeks 2006-08-18 20:56:47 UTC
So - the patch above fixes the number formatting issues, so if the field is a
number, but rendered as a date / etc. we get numeric sorting right too.

I'd love to know of any other potential issues; thankfully an easy fix. I'd love
to avoid having to create a CWS with 'sw' in it though ;-) any helpful hackers
want to include this ?
Comment 11 Oliver Specht 2006-08-22 09:48:12 UTC
.
Comment 12 Oliver Specht 2006-09-04 13:38:41 UTC
Patch applied in cws os86
Comment 13 Oliver Specht 2006-09-06 10:22:42 UTC
Reassigned for verification
Comment 14 michael.ruess 2006-09-08 15:45:35 UTC
Verified fix in CWS os86.
Comment 15 michael.ruess 2006-10-06 14:37:57 UTC
Checked in 680m186.
Comment 16 Rainer Bielefeld 2006-10-31 17:52:51 UTC
Can someone please be so kind and check whether the fix also heals the sort
problems reported in issue 60681:
- known numeric sort order problem from this issue here 
  Attachment issue 60681 'Sorting problems in tables.odt' part 1
- Alphanumeric sort order with fields
  Attachment issue 60681 'Sorting problems in tables.odt' part 1
- General alphanumeric sort order problem 
  Attachment issue 60681 'myowntest.odt'

Thanks!
Comment 17 Joe Smith 2006-10-31 19:36:16 UTC
> problems reported in issue 60681:
> - known numeric sort order problem from this issue here 

Confirmed: sort by "Numeric" key fails unless cell format is also numeric
(i.e. problem reported in this issue, 49629, is still present)

Note: sorting numbers by "Alphanumeric" key does not sort by the number value.
It may produce the expected order for the 'Sorting problems in tables.odt' part
1 case, but only because the numbers in column 1 all have one digit. If you
change 3 to 33, and sort by column 1 "Alphanumeric", it will fall between 2 and 4.

The only workaround for the problem in this issue (49629) is to assign a numeric
number format to the cell data.

> - Alphanumeric sort order with fields
>   Attachment issue 60681 'Sorting problems in tables.odt' part 1 [part 2?]

Confirmed. Sort by either "Numeric" or "Alphanumeric" key, with either Text or
Number/General number format, does not result in correctly ordered rows.

Sorting of simple "set variable" "var=n" fields does not sort numerically
either, even when the field has a numeric format.

> - General alphanumeric sort order problem 
>   Attachment issue 60681 'myowntest.odt'

Confirmed. Sort descending works; ascending does not.

Sorting the table contents as text paragraphs (i.e. copied out of the table)
works for both directions.

These were confirmed using OOo 2.0.4rc3 [680m5(Build:9073)] under Fedora Linux 5.

*** Note ***
I think something weird may be happening. As I was trying different combinations
of formats and sort options, sorting that had failed previously started working.
Restarting OOo and repeating the test went back to the previous failing
behavior, so the problem may not be 100% reproducible, or I may simply be confused.
Comment 18 Joe Smith 2006-10-31 19:43:57 UTC
> Verified fix in CWS os86.

Note that release notes for 2.0.4 do not indicate that "os86" is included in the
release, so it is not suprising that the problem reported here and confirmed in
my previous comment is still present in 2.0.4.

Guess I should have checked that first.
Comment 19 Rainer Bielefeld 2006-10-31 20:15:59 UTC
@jes:
Of course, all that must be checked with a build containing the fix for issue
49629,  we will see what of those issue 60681 are already fixed.
I also noticed your "weird effect", in the mornign I was able to do some sorting
without problem, that failed (as I had expected) in the evening.
Comment 20 Rainer Bielefeld 2006-12-07 06:55:07 UTC
*** Issue 72345 has been marked as a duplicate of this issue. ***
Comment 21 Joe Smith 2006-12-07 23:23:04 UTC
Updating tests based on 2.1.0rc2 (680m6), on Fedora Linux 5

> problems reported in issue 60681:
> - known numeric sort order problem from this issue here 

FIXED -- Sort > Numeric now works properly for numeric data regardless of the
cell format (Text or Number/*)

> - Alphanumeric sort order with fields
>   Attachment issue 60681 'Sorting problems in tables.odt' part 1 [part 2?]

Confirmed. No change. Fields are not sorted properly for any conditions.

> - General alphanumeric sort order problem 
>   Attachment issue 60681 'myowntest.odt'

This is INVALID.

The problem with sorting in the sample document is that the Table properties >
Text Flow > Repeat heading is set to 1. This causes the sort operation to
exclude the first row from the sort. It is a mere coincidence that the
descending order example happens to work. If you change the data order so that
the first row must move, then the descending example produces wrong results as well.

My conclusions:
Issue 49629 is correctly CLOSED FIXED
Issue 60681 is correctly RESOLVED DUPLICATE:
  problem #1 is also fixed by this issue
  problem #2 is a duplicate of 33772
  problem #3 is invalid