OpenJPA
  1. OpenJPA
  2. OPENJPA-2086

OracleDictionary setFixed and setFormOfUse(NCLOB) are not really doing what they should.

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 2.1.1, 2.2.0
    • Fix Version/s: None
    • Component/s: jdbc
    • Environment:
      Oracle 9g, 10g and 11g

      Description

      The setString() method in the OracleDictionary tries to be smart and and look up the column type, and detect and apply nchar and/or fixed char semantics.
      However, I believe that the type information is normally not present for queries, and the functions are never called.

      That means that characters outside the database character set will be lost during translation, and that comparison on CHAR (fixed length) columns will not match if
      the arguments are not padded to the column length.

      I suggest that the special nchar handling is removed as it is not working properly. The only "reliable" option is to set the connection property oracle.jdbc.defaultNChar=true,
      as it would be neigh impossible to get this right in an automatic way.
      (Actually, the sensible option is to convert the database to AL32UTF8, and not use nchars at all since Oracles nchar handling seems to be problematic. )

      Further as the fixedString handling also does not work without type information, the dictionary could either always, or depending on a flag,
      call the setFixedChar() method, or just rely on the connection parameter "fixedString" (and use setObject), avoiding the complexity (and the cost of reflection calls) altogether.

        Activity

        Hide
        Karl PIhlblad added a comment -

        After some more investigation, it seems as if defaultNChar=true is not a good strategy,
        as it prevents Oracle's optimizer to use char/varchar indexes for nchar parameters. Sigh...

        Using @Column(columnDefinition) is then perhaps the only solution but that will fail for constructs when comparing against functions:
        eg; param = UPPER( col ), param = TRIM( col), etc.

        However, unless a better solution is available, I think the conclusion is to stick with columnDefinition, and convert the database character if neccesary...

        Also, unfortunately, setObject() seems to be depending on what PreparedStatement implementation is used. On WebSphere, WsPreparedStatment, or perhaps the
        WebSphere variant of OracleDictionary fails to get the 'fixed' semantics right. Again, I suppose using the columnDefinition is the best shot...

        Show
        Karl PIhlblad added a comment - After some more investigation, it seems as if defaultNChar=true is not a good strategy, as it prevents Oracle's optimizer to use char/varchar indexes for nchar parameters. Sigh... Using @Column(columnDefinition) is then perhaps the only solution but that will fail for constructs when comparing against functions: eg; param = UPPER( col ), param = TRIM( col), etc. However, unless a better solution is available, I think the conclusion is to stick with columnDefinition, and convert the database character if neccesary... Also, unfortunately, setObject() seems to be depending on what PreparedStatement implementation is used. On WebSphere, WsPreparedStatment, or perhaps the WebSphere variant of OracleDictionary fails to get the 'fixed' semantics right. Again, I suppose using the columnDefinition is the best shot...
        Hide
        Karl PIhlblad added a comment -

        After some investigation, it seems as if the nchar information is gathered from the @Column( columnDefintion ) attribute.

        However, The documentation states that the attribute "is only used by vendors that support creating tables from your mapping metadata.",
        and nothing is mentioned in the OracleDictionary properties section.

        Regarding setFixedChar; The type information doesn't seem to be available for dynamic columns,
        as the type seems to be set from a "template" VARCHAR(255). I suppose it means "a big string"

        Show
        Karl PIhlblad added a comment - After some investigation, it seems as if the nchar information is gathered from the @Column( columnDefintion ) attribute. However, The documentation states that the attribute "is only used by vendors that support creating tables from your mapping metadata.", and nothing is mentioned in the OracleDictionary properties section. Regarding setFixedChar; The type information doesn't seem to be available for dynamic columns, as the type seems to be set from a "template" VARCHAR(255). I suppose it means "a big string"

          People

          • Assignee:
            Unassigned
            Reporter:
            Karl PIhlblad
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development