Bug #730 getXXX after updateXXX does not return the good value.
Submitted: 26 Jun 2003 7:05 Modified: 26 Jun 2003 7:24
Reporter: David Marquis Email Updates:
Status: Not a Bug Impact on me:
None 
Category:Connector / J Severity:S2 (Serious)
Version:3.1 OS:Windows (Win2k)
Assigned to: CPU Architecture:Any

[26 Jun 2003 7:05] David Marquis 
Description:
A call to getXXX after an updateXXX always returns the old value. 

This follows up bugs #675.

This is caused by the fact that only the updater (PreparedStatement) gets updated when any updateXXX is called.
The internal data (thisRow) should also be updated.

How to repeat:
See bug #675, do the same thing, but in update mode instead of insert mode

Suggested fix:
Replace the updater (updateXXX) methods from :

public synchronized void updateBoolean(int columnIndex, boolean x)
        throws SQLException {
        if (!onInsertRow) {
            if (!doingUpdates) {
                doingUpdates = true;
                syncUpdate();
            }

            updater.setBoolean(columnIndex, x);
        } else {
            inserter.setBoolean(columnIndex, x);

            this.thisRow[columnIndex - 1] = inserter.getBytesRepresentation(1);
        }
    }

TO:

public synchronized void updateBoolean(int columnIndex, boolean x)
        throws SQLException {
        if (!onInsertRow) {
            if (!doingUpdates) {
                doingUpdates = true;
                syncUpdate();
            }

            updater.setBoolean(columnIndex, x);
            this.thisRow[columnIndex - 1] = updater.getBytesRepresentation(1);
        } else {
            inserter.setBoolean(columnIndex, x);

            this.thisRow[columnIndex - 1] = inserter.getBytesRepresentation(1);
        }
        
    }
[26 Jun 2003 7:24] Mark Matthews 
This is JDBC-compliant, and is as designed. If you check the return value from DatabaseMetaData.ownUpdatesAreVisible(), you will see that it returns false, which means changes to updatable result sets are not visible until updateRow() is called.

Refer to the JDBC-2.0 spec, section 5.8.3 for more information.
[14 Jul 2008 14:44] Bugs System 
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/49683

2648 Georgi Kodinov	2008-07-14
      Bug#37830: ORDER BY ASC/DESC - no difference
      
      Range scan in descending order for c <= <col> <= c type of
      ranges was ignoring the DESC flag.
      However some engines like InnoDB have the primary key parts 
      as a suffix for every secondary key.
      When such primary key suffix is used for ordering ignoring 
      the DESC is not valid.
      But we generally would like to do this because it's faster.
      Fixed by adding a special flag to QUICK_SELECT_DESC to respect
      reverse ordering and read the EQ_RANGE backwards.
[15 Jul 2008 8:46] Bugs System 
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/49738

2648 Georgi Kodinov	2008-07-15
      Bug#37830: ORDER BY ASC/DESC - no difference
            
      Range scan in descending order for c <= <col> <= c type of
      ranges was ignoring the DESC flag.
      However some engines like InnoDB have the primary key parts 
      as a suffix for every secondary key.
      When such primary key suffix is used for ordering ignoring 
      the DESC is not valid.
      But we generally would like to do this because it's faster.
      Fixed by adding a special flag to QUICK_SELECT_DESC to respect
      reverse ordering and read the EQ_RANGE backwards.