Uploaded image for project: 'Teiid'
  1. Teiid
  2. TEIID-4446

Rationalize precision/scale

XMLWordPrintable

      Our handling of precision/scale is inconsistent. There are assumptions being made in the JDBC client, types.dat, the parser, and other paths that need to be explicit and consistent.

          1.
          		 ODBC "Parse Statements" option can result in changes in LENGTH metadata for columns Sub-task Closed Minor Steven Hawkins

            [TEIID-4446] Rationalize precision/scale

            RH Bugzilla Integration added a comment -

            Van Halbert <vhalbert@redhat.com> changed the Status of bug 1451867 from MODIFIED to ON_QA

            RH Bugzilla Integration added a comment - Van Halbert <vhalbert@redhat.com> changed the Status of bug 1451867 from MODIFIED to ON_QA

            RH Bugzilla Integration added a comment -

            Van Halbert <vhalbert@redhat.com> changed the Status of bug 1451867 from ASSIGNED to MODIFIED

            RH Bugzilla Integration added a comment - Van Halbert <vhalbert@redhat.com> changed the Status of bug 1451867 from ASSIGNED to MODIFIED

            RH Bugzilla Integration added a comment -

            Van Halbert <vhalbert@redhat.com> changed the Status of bug 1451867 from NEW to ASSIGNED

            RH Bugzilla Integration added a comment - Van Halbert <vhalbert@redhat.com> changed the Status of bug 1451867 from NEW to ASSIGNED

            Steven Hawkins added a comment -

            Updated the code so that we are consistently handling precision/scale. A nominal internal max of max short was introduced as the max precision (half that for scale) when precision is left unspecified - as those are safe for jdbc/odbc/odata metadata (jdbc expects a short scale, and odbc can only properly encode unsigned short). However for backwards compatibility at for now we won't throw an exception if larger values are set.

            Steven Hawkins added a comment - Updated the code so that we are consistently handling precision/scale. A nominal internal max of max short was introduced as the max precision (half that for scale) when precision is left unspecified - as those are safe for jdbc/odbc/odata metadata (jdbc expects a short scale, and odbc can only properly encode unsigned short). However for backwards compatibility at for now we won't throw an exception if larger values are set.

              rhn-engineering-shawkins Steven Hawkins
              rhn-engineering-shawkins Steven Hawkins
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: