GeoTools
  1. GeoTools
  2. GEOT-3382

Incorrect offset in updateSQLPS causing Invalid column index.

    Details

    • Type: Bug Bug
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:
      Geoserver 2.1-RC1
      using Geotool 2.7-beta1
      Update generated from openlayers (hosted in a GWT env)
      Updated applied to oracle datastore.

      Description

      line 3762
      setPreparedFilterValues(ps, toSQL, i, cx);

      passes the value i as the offset for the index to use to apply the filter.

      this value is then used on line 2970

      dialect.setValue( value, binding, ps, offset + i+1, cx );

      (at this point offset as the value of i and i has the value of zero) it generates an Invalid column index.

      This is because i (in the original scope) was tracking source attribute value index, not query variable. These two values go out of sync on line 3704,when the primary key is skipped.

      If line 3762 was replaced by
      setPreparedFilterValues(ps, toSQL, j, cx);
      the problem would be solved.

        Activity

        Hide
        Andrea Aime added a comment -
        Sounds a bit odd, we do have unit tests for updates. Maybe it's happening in combination with some specific PK treatment code? Like, for example, making the primary key part of the returned feature attributes?
        The best way to get a quick fix on this would be to provide a patch along with one or more tests proving the issue has been solved (and making sure it won't get broken again as a result of other code changes)
        Show
        Andrea Aime added a comment - Sounds a bit odd, we do have unit tests for updates. Maybe it's happening in combination with some specific PK treatment code? Like, for example, making the primary key part of the returned feature attributes? The best way to get a quick fix on this would be to provide a patch along with one or more tests proving the issue has been solved (and making sure it won't get broken again as a result of other code changes)
        Hide
        Richard Sunderland added a comment -
        Further research shows,

        It only happens if
        1) you are using a PreparedStatementDialect (this includes at least Oracle and a believe PostGIS)
        2) you are using a filter != null && filter != includes
        3) you have the primary key in your list of attributes.

        By setting expose primary keys to false on the datastore we invalidate (3) so we are using this a workaround.

        As we have a work around, I can not progress this urgently. However, will attempt to create testcase and patch in longer time.
        Show
        Richard Sunderland added a comment - Further research shows, It only happens if 1) you are using a PreparedStatementDialect (this includes at least Oracle and a believe PostGIS) 2) you are using a filter != null && filter != includes 3) you have the primary key in your list of attributes. By setting expose primary keys to false on the datastore we invalidate (3) so we are using this a workaround. As we have a work around, I can not progress this urgently. However, will attempt to create testcase and patch in longer time.

          People

          • Assignee:
            Unassigned
            Reporter:
            Richard Sunderland
          • Votes:
            2 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated: