Hi,
There is an issue with OracleNG which is retrograde. I did not have this
problem in 1.7.0.
This error ...
11 Dec 22:54:04 ERROR [geotools.rendering] - Could not determine fid
from primary key
occurs when selecting an Oracle view as a feature type, even when the
view is on a single table with a single column primary key.
This is written by JDBCDataStore.getPrimaryKey as a warning.
11 Dec 23:24:01 WARN [geotools.jdbc] - No primary key found for
LANDPARCELS.
And the following line states that the feature type was loaded.
11 Dec 23:24:37 INFO [geoserver.catalog] - Loaded feature type
'topp:LANDPARCELS'
But when accessing the feature via wms JDBCFeatureReader.next() calls
fid = dataStore.encodeFID(pkey,rs);
with a null pkey resulting in the following exception
11 Dec 22:54:04 ERROR [geotools.rendering] - Could not determine fid
from primary key
java.lang.RuntimeException: Could not determine fid from primary key
at
org.geotools.jdbc.JDBCFeatureReader.next(JDBCFeatureReader.java:265)
<etc>.
The obvious issue with this is that "no primary key" is only a warning
but later proves fatal.
Five possible solutions:
1. Easiest - don't allow views - check the object type and reject
submission.
2. Easy - check for primary key when creating feature and make lack
of primary key prevent submission.
3. Moderate - check object type at creation and allow admin to
specify primary key (Competent admins would understand the issues of the
specified column not being uniquely indexed).
4. Moderate - allow no primary key - but also no transactions. An fid
should only be needed for WFS.
5. Hardest - check the view definition and if it is an updateable
view, then it has a primary key.
In any case, just relying on the ojdbc call and assuming only tables are
submitted by admins will not solve the issue.
Options 1 and 2 are not acceptable real world solutions.
Option 5 may be easier than I think - but at the moment I think it goes
in the too-hard basket - there could be many complex scenarios.
Option 4 requires a code change but does not properly solve the problem
where there are valid reasons for using a view and the view is and
should be updateable.
Option 3, IMHO, offers the only viable solution in the short term.
Regards
Stuart
------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
