Uploaded image for project: 'OpenJPA'
  1. OpenJPA
  2. OPENJPA-745

Sybase by default silently truncates a string which is longer than the column length without raising an exception

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 1.2.0
    • Fix Version/s: 1.2.1, 1.3.0
    • Component/s: None
    • Labels:
      None

      Description

      By default, Sybase silently truncates a string which is longer than the column length without raising an exception. To override this behavior, string_rtruncation must be set on. In order to be consistent with other databases (which raise exceptions when a string length is longer than the column length), we will set string_rtruncation on by default for Sybase. For an application that wants to keep Sybase silent truncation behavior, a DBDictionary property "setStringRightTruncationOn" is introduced. When it is set to false in the persistence.xml, the string will be silently truncated during insert/update.

      1. OPENJPA-745.patch
        3 kB
        Fay Wang
      2. OPENJPA-745-1.patch
        3 kB
        Fay Wang

        Issue Links

          Activity

          Hide
          ppoddar@apache.org Pinaki Poddar added a comment -

          Following part of the patch in JDBCStoreManager appears to be too specifc

          public Connection getConnection() {
          connect(true);
          + try

          { + _dict.raiseRightTruncationException(_conn); + }

          catch (SQLException se)

          { + throw SQLExceptions.getStore(se, _dict); + }

          return _conn;
          }

          Suggested
          a) more generic name such as DBDictionary.setConnection(Connection conn) or DBDictionary.initializeSettings(Connection conn) or similar.
          b) more importantly, the more appropriate location for this invocation is internal connect(boolean) method itself where the exception handling is carried out.

          Show
          ppoddar@apache.org Pinaki Poddar added a comment - Following part of the patch in JDBCStoreManager appears to be too specifc public Connection getConnection() { connect(true); + try { + _dict.raiseRightTruncationException(_conn); + } catch (SQLException se) { + throw SQLExceptions.getStore(se, _dict); + } return _conn; } Suggested a) more generic name such as DBDictionary.setConnection(Connection conn) or DBDictionary.initializeSettings(Connection conn) or similar. b) more importantly, the more appropriate location for this invocation is internal connect(boolean) method itself where the exception handling is carried out.
          Hide
          faywang Fay Wang added a comment -

          The attached patch is per Pinaki's suggestion. Thanks for your feedback!

          Show
          faywang Fay Wang added a comment - The attached patch is per Pinaki's suggestion. Thanks for your feedback!
          Hide
          mikedd Michael Dick added a comment -

          Shouldn't :
          — openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/kernel/JDBCStoreManager.java (revision 706319)
          +++ openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/kernel/JDBCStoreManager.java (working copy)
          @@ -920,6 +920,7 @@
          try

          { // connect if the connection is currently null, or if // the connection has been closed out from under us if (_conn == null) _conn = connectInternal(); if (ref) _conn.ref(); + _dict.initializeSettings(_conn); }

          catch (SQLException se)

          { throw SQLExceptions.getStore(se, _dict); } finally {


          actually be
          try {
          // connect if the connection is currently null, or if
          // the connection has been closed out from under us
          - if (_conn == null)
          + if (_conn == null) { _conn = connectInternal(); + _dict.initializeSettings(_conn); + }
          if (ref)
          _conn.ref();
          } catch (SQLException se) { throw SQLExceptions.getStore(se, _dict); }

          finally {

          It seems like we'd only need to set the truncation property the first time we obtain a connection, not every time the store uses it.

          Show
          mikedd Michael Dick added a comment - Shouldn't : — openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/kernel/JDBCStoreManager.java (revision 706319) +++ openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/kernel/JDBCStoreManager.java (working copy) @@ -920,6 +920,7 @@ try { // connect if the connection is currently null, or if // the connection has been closed out from under us if (_conn == null) _conn = connectInternal(); if (ref) _conn.ref(); + _dict.initializeSettings(_conn); } catch (SQLException se) { throw SQLExceptions.getStore(se, _dict); } finally { actually be try { // connect if the connection is currently null, or if // the connection has been closed out from under us - if (_conn == null) + if (_conn == null) { _conn = connectInternal(); + _dict.initializeSettings(_conn); + } if (ref) _conn.ref(); } catch (SQLException se) { throw SQLExceptions.getStore(se, _dict); } finally { It seems like we'd only need to set the truncation property the first time we obtain a connection, not every time the store uses it.
          Hide
          faywang Fay Wang added a comment -

          commit with r706493 and r706494.

          Show
          faywang Fay Wang added a comment - commit with r706493 and r706494.
          Hide
          faywang Fay Wang added a comment -

          make the fix in synch with the fix in OPENJPA-750. commit in openjpa truck with r-707214 and in openjpa 1.2.x with r-707222.

          Show
          faywang Fay Wang added a comment - make the fix in synch with the fix in OPENJPA-750 . commit in openjpa truck with r-707214 and in openjpa 1.2.x with r-707222.

            People

            • Assignee:
              Unassigned
              Reporter:
              faywang Fay Wang
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development