[fdo-internals] primary key on views for rdbms providers?

Orest Halustchak orest.halustchak at autodesk.com
Tue Jul 8 08:30:10 EDT 2008

Oracle provides a way to specify a pk for a view.

alter view <viewname> add constraint <constraintname> primary key (<columnlist>) disable novalidate;

This pk is not enforced but provides information about what pk makes sense for the data in the view.

I haven't tried this with the king oracle provider to see if it would be recognized.

It's hard to guess a possible pk for a view (in an automated way) unless the view is a simple select from a single table, and the select includes the underlying table's pk columns. If there is a join involved, it's more complicated.


From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Kenneth Skovhede, GEOGRAF A/S
Sent: Tuesday, July 08, 2008 4:29 AM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] primary key on views for rdbms providers?

I don't think king.oracle works on views without setup in the helper table.

If it is possible to detect/guess the PK in any way, that would the
best solution IMO (less user action required).

The ability to override and otherwise setup the datasource is nice.
You could put it in a config document rather than a special table.
There are pros and cons for both I think.

Regards, Kenneth Skovhede, GEOGRAF A/S

Bruno Scott skrev:

Yes it's true,

But king.oracle can also work wihout this helper table!

Does it support selection on views without the helper table?

Do you think adding this king of helper table in the PostGIS provider is a

good approach?


Kenneth Skovhede, GEOGRAF A/S wrote:

The Oracle provider does this with a special helper table:


Regards, Kenneth Skovhede, GEOGRAF A/S

Bruno Scott skrev:

I'm facing a problem in the PostGIS provider when mapping a view to a



How to determine wich column will serves as primary key.

Is there a way in PostGIS to know wich one?

And on a more general perspective, what if there is more than one primary

key in the view's based tables? Is there a rule of thumb we could use?

How did you manage to resolve this question in providers like


When there is no primary key on a feature class, the selection in


does not work!




fdo-internals mailing list

fdo-internals at lists.osgeo.org<mailto:fdo-internals at lists.osgeo.org>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo-internals/attachments/20080708/6a02194b/attachment.html

More information about the fdo-internals mailing list