Following on from this earlier question I\'m on PostgreSQL 8.4 and am having trouble with updatable views.
I have a view:
CREATE VIEW filedata_view
A
Don't use a rule for this, but a trigger. You need at least version 9.1, older versions don't support triggers on views.
A trigger is a specification that the database should automatically execute a particular function whenever a certain type of operation is performed. Triggers can be attached to both tables and views.
On tables, triggers can be defined to execute either before or after any INSERT, UPDATE, or DELETE operation, either once per modified row, or once per SQL statement. UPDATE triggers can moreover be set to fire only if certain columns are mentioned in the SET clause of the UPDATE statement. Triggers can also fire for TRUNCATE statements. If a trigger event occurs, the trigger's function is called at the appropriate time to handle the event.
Rumor is that rules will be EOL in a while.
If you have Postgres >= 9.3 you can update features coming from a View with GeoServer, at least if the view is a subset of another table (I don't think this will work with joins or compound fields..).
Here's how: http://osgeo-org.1560.x6.nabble.com/postgresql-postgis-views-and-primary-keys-td3796362.html
This really worked for me!
First, I couldn't agree more with Frank. Use 9.1, and a table trigger. However, it's possible that neither that nor a view will solve your problem.
Try doing a manual UPDATE
on your view from psql. If that works, and if you connect using the same user ID with opengeospatial, then I'd say the issue could be opengeospatial being too clever for its own good and "knowing" that views can't be updated. Either that, or it's trying an INSERT
and you haven't added a matching INSERT
rule on your view.
The message "filedata_view is read-only" isn't a message PostgreSQL may produce. I'm wondering if opengeospatial is using JDBC metadata (assuming it's Java) or INFORMATION_SCHEMA or similar to query the schema, is determining that filedata_view
is a view, and is concluding that it therefore can't update it.
If it were a message from PostgreSQL it would instead say:
# UPDATE customer_v SET customer_number = 1234;
ERROR: cannot update view "the_view"
HINT: You need an unconditional ON UPDATE DO INSTEAD rule or an INSTEAD OF UPDATE trigger.
It might be informative to enable log_statement = 'all'
in postgresql.conf
and reload postgresql. Re-test, then look in the logs see what exactly opengeospatial is doing.
If it turns out it's detecting a view, you might be able to work around the problem with an ON SELECT
rule added to an empty table. The table will work just like a view, but GeoServer won't be able to tell it is a view and might agree to write to it.