No KML output when Oracle datasource

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?

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

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

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?

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)

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

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

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)

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.

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

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.

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.

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.

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?

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

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)