GeoServer
  1. GeoServer
  2. GEOS-2526

No KML output when Oracle datasource

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: 1.7.1
    • Fix Version/s: 1.7.2
    • Labels:
      None
    • Environment:
      XP and RedHat 5.2
    • Number of attachments :
      0

      Description

      When using an Oracle (10g) datasource, no KML output is rendered in GoogleEarth EC (4.3.7297.6367). Both Jetty and Tomcat distributions behave the same way. Rolling back to 1.7.0 resolves the issue.

        Issue Links

          Activity

          Hide
          Andrea Aime added a comment -

          Ilya, which version of the Oracle plugin did you use, the NG one or the classic one?
          David, did we add any specific requirement in 1.7.1 for data to be turned into KML?

          Show
          Andrea Aime added a comment - Ilya, which version of the Oracle plugin did you use, the NG one or the classic one? David, did we add any specific requirement in 1.7.1 for data to be turned into KML?
          Hide
          Ilya Rosenfeld added a comment -

          Andrea,

          The Oracle plugin (classic) was the one bundled with the geoserver 1.7.1 distribution. The problem is that when Oracle datasource is used, KML output invoked from the demo page (or otherwise) comes up empty, while all other formats launch fine (pdf, georss, svg, etc). KML is fine when shapefile datasources are used.

          -Ilya

          Show
          Ilya Rosenfeld added a comment - Andrea, The Oracle plugin (classic) was the one bundled with the geoserver 1.7.1 distribution. The problem is that when Oracle datasource is used, KML output invoked from the demo page (or otherwise) comes up empty, while all other formats launch fine (pdf, georss, svg, etc). KML is fine when shapefile datasources are used. -Ilya
          Hide
          Andrea Aime added a comment -

          Hum, let me guess... your tables do not have a primary key?

          Show
          Andrea Aime added a comment - Hum, let me guess... your tables do not have a primary key?
          Hide
          Ilya Rosenfeld added a comment -

          I'm far from that Oracle instance and can't check right now.. However, can this possibly be the problem since rolling back to geoserver 1.7.0 solves the issue while the same exact tables are used?

          Show
          Ilya Rosenfeld added a comment - I'm far from that Oracle instance and can't check right now.. However, can this possibly be the problem since rolling back to geoserver 1.7.0 solves the issue while the same exact tables are used?
          Hide
          Andrea Aime added a comment -

          It's a distinct possibility since 1.7.1 uses a whole different way of generating KML, superoverlays have been enabled by default (they weren't ready for 1.7.0 and have been delayed to 1.7.1)

          Show
          Andrea Aime added a comment - It's a distinct possibility since 1.7.1 uses a whole different way of generating KML, superoverlays have been enabled by default (they weren't ready for 1.7.0 and have been delayed to 1.7.1)
          Hide
          Ilya Rosenfeld added a comment -

          Okay.. I'll check this out over the next couple of days and let you know..

          Show
          Ilya Rosenfeld added a comment - Okay.. I'll check this out over the next couple of days and let you know..
          Hide
          Ilya Rosenfeld added a comment -

          Adding a primary key to Oracle tables solves the "empty KML output" issue.

          Show
          Ilya Rosenfeld added a comment - Adding a primary key to Oracle tables solves the "empty KML output" issue.
          Ilya Rosenfeld made changes -
          Field Original Value New Value
          Status Open [ 1 ] Resolved [ 5 ]
          Fix Version/s 1.7.1 [ 14502 ]
          Resolution Fixed [ 1 ]
          Hide
          Andrea Aime added a comment - - edited

          I'd like to keep it open until David has the occasion to comment and eventually fix the issue. As you noticed, previosly KML output was generated also in abscence of primary keys (thus it sounds like a regression)

          Show
          Andrea Aime added a comment - - edited I'd like to keep it open until David has the occasion to comment and eventually fix the issue. As you noticed, previosly KML output was generated also in abscence of primary keys (thus it sounds like a regression)
          Andrea Aime made changes -
          Status Resolved [ 5 ] Reopened [ 4 ]
          Resolution Fixed [ 1 ]
          Andrea Aime made changes -
          Fix Version/s 1.7.2 [ 14681 ]
          Fix Version/s 1.7.1 [ 14502 ]
          Hide
          Justin Deoliveira added a comment -

          Yeah... this is b/c the default is not regionating and that requires primary keys, or just a repeatable fid. I thought there was another issue open for this. I guess the fix discussed was adding some flag to the datastore / feature source capabilities reporting if it can create reliable fids.

          Show
          Justin Deoliveira added a comment - Yeah... this is b/c the default is not regionating and that requires primary keys, or just a repeatable fid. I thought there was another issue open for this. I guess the fix discussed was adding some flag to the datastore / feature source capabilities reporting if it can create reliable fids.
          Hide
          Andrea Aime added a comment -

          And disable regionating in the cases in which the fid is not repeatable, and fall back to the old behaviour?

          Show
          Andrea Aime added a comment - And disable regionating in the cases in which the fid is not repeatable, and fall back to the old behaviour?
          Hide
          David Winslow added a comment -

          Right, the problem is that when fid's are not consistent between requests, the regionating code doesn't output any features at all. The proposed fix is to change the reflector so that it doesn't default to regionating when the datastore doesn't support it (it would go back to the old onstop + kmscore method). For that to happen, we need some way of detecting whether the datastore provides consistent fids. The JIRA issue is GEOS-2467.

          Show
          David Winslow added a comment - Right, the problem is that when fid's are not consistent between requests, the regionating code doesn't output any features at all. The proposed fix is to change the reflector so that it doesn't default to regionating when the datastore doesn't support it (it would go back to the old onstop + kmscore method). For that to happen, we need some way of detecting whether the datastore provides consistent fids. The JIRA issue is GEOS-2467 .
          Andrea Aime made changes -
          Link This issue is related to GEOS-2467 [ GEOS-2467 ]
          Hide
          Ilya Rosenfeld added a comment -

          A couple of ideas:

          • Technically speaking, there is always a unique pseudo-key "ROWID" on all oracle tables whether a primary key is explicitly declared or not. Perhaps there is a way to use that as a default feature id;
          • Whether a table has a primary key can be determined by directly querying "all_constraints" table.
          Show
          Ilya Rosenfeld added a comment - A couple of ideas: Technically speaking, there is always a unique pseudo-key "ROWID" on all oracle tables whether a primary key is explicitly declared or not. Perhaps there is a way to use that as a default feature id; Whether a table has a primary key can be determined by directly querying "all_constraints" table.
          Hide
          Andrea Aime added a comment -

          As far as I know rowid is the number of the row returned by the query, not the number of the row in the table, is it?. What we need is a value stable enough not to be altered by changing the query used to access data.
          As for the pk, we use JDBC database metadata to figure out the pk and when there is one, we get it... if you have cases in which there is a pk but the datastore does not figure it out properly I'm defninitely interested in hearing about it.

          Show
          Andrea Aime added a comment - As far as I know rowid is the number of the row returned by the query, not the number of the row in the table, is it?. What we need is a value stable enough not to be altered by changing the query used to access data. As for the pk, we use JDBC database metadata to figure out the pk and when there is one, we get it... if you have cases in which there is a pk but the datastore does not figure it out properly I'm defninitely interested in hearing about it.
          Hide
          Ilya Rosenfeld added a comment -

          I think you are talking about ROWNUM, which enumerates query results. ROWID is actually in the database.. it's necessary to uniquely identify rows by the system. I guess the question is whether JDBC exposes it.. And I think you're right on the pk metadata - it's definitely more efficient if separate queries don't have to be run. The only case I can think of where JDBC metadata can get out of sync with the actual schema is when schema DDL gets tweaked while a JDBC connection instance is alive.. but that's probably handled via JDBC locks and/or exceptions, no?

          Show
          Ilya Rosenfeld added a comment - I think you are talking about ROWNUM, which enumerates query results. ROWID is actually in the database.. it's necessary to uniquely identify rows by the system. I guess the question is whether JDBC exposes it.. And I think you're right on the pk metadata - it's definitely more efficient if separate queries don't have to be run. The only case I can think of where JDBC metadata can get out of sync with the actual schema is when schema DDL gets tweaked while a JDBC connection instance is alive.. but that's probably handled via JDBC locks and/or exceptions, no?
          Hide
          Andrea Aime added a comment -

          Aaah, rowid and rownum... doh, right, I only knew about rownum. So yeah, that looks like a very good candidate. Wondering what would happen if the "table" in question is actually a view.
          Looking around in forums, it seems it is, under the condition that the view is a "key preserved table", see here: http://igor.gold.ac.uk/oracle/9i/server.920/a96521/views.htm

          Show
          Andrea Aime added a comment - Aaah, rowid and rownum... doh, right, I only knew about rownum. So yeah, that looks like a very good candidate. Wondering what would happen if the "table" in question is actually a view. Looking around in forums, it seems it is, under the condition that the view is a "key preserved table", see here: http://igor.gold.ac.uk/oracle/9i/server.920/a96521/views.htm
          Andrea Aime made changes -
          Link This issue relates to GEOT-2252 [ GEOT-2252 ]
          Andrea Aime made changes -
          Status Reopened [ 4 ] Closed [ 6 ]
          Resolution Duplicate [ 3 ]
          Hide
          Andrea Aime added a comment -

          Closing as the real action will take place in the related jiras (native pk mapping strategy, having the reflector work when no pk is available)

          Show
          Andrea Aime added a comment - Closing as the real action will take place in the related jiras (native pk mapping strategy, having the reflector work when no pk is available)

            People

            • Assignee:
              Andrea Aime
              Reporter:
              Ilya Rosenfeld
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: