Closed tudorbarascu closed 6 years ago
Hmmm. I don't think so.
Triggers have to be rewritten, actually they still are calling handling_altitude
when new attribute is called altitude
.
CREATE TRIGGER valve_handle_altitude_update_trigger
BEFORE UPDATE OF handle_altitude, handle_geometry
ON qwat_od.valve
FOR EACH ROW
WHEN (((new.handle_altitude <> old.handle_altitude) OR (st_z(new.handle_geometry) <> st_z(old.handle_geometry))))
EXECUTE PROCEDURE qwat_od.ft_valve_handle_altitude();
COMMENT ON TRIGGER valve_handle_altitude_update_trigger ON qwat_od.valve IS 'Trigger: when updating, check if altitude or Z value of geometry changed and synchronize them.';
@haubourg and @3nids I thought we should only go editing through views in a thick database. Why are we going through tables directly here? Same question could apply to pipes.
I know there were some simplifications in the inheritance but is it really a good thing to have 51 attributes into the valve table instead of 13? and mainly are just technical attributes for labeling and geometry, mainly common to all point features (nodes if I dare the word).
If they are no water network nodes, they still are point features right?
Should we discuss this at the next PSC?
@ponceta I don't see how vw_valve_lines.sql is deprecated?
@3nids vw_valve_lines.sql is not deprecated, indeed. Thanks for the fix.
@3nids It doesn't work, not on insert and not on update. E.g. Adding a 200 altitude the geometry z is 0, same when updating with another altitude.
SRID is missing
For the hydrants and all the elements that are edited through
vw_element_*
the altitude is synced with the geometry.In the current model (1.2.7) the valves don't have this functionality although they had it when they were edited through the old
vw_element_valve
view.Is this intentional?