DeleteObservation throws NullPointerException when deleting last observation in series?

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

DeleteObservation throws NullPointerException when deleting last observation in series?

TSlawecki
I am working though the use case of deleting an observation that was entered using InsertResult. I do the following:

1. Since InsertResult does not currently assign a value to the observation:identifier field, I use psql to execute the following statement:

  UPDATE observation SET identifier = 'o' || observationid::text

2. I use a GetObservation query to get the identifier value for the observation I would like to delete:

http://ec2-35-166-3-66.us-west-2.compute.amazonaws.com:8080/52n-sos-webapp/service?service=SOS&version=2.0.0&request=GetObservation&procedure=urn:x-epaiwpp:sensor:njdep:bfbm:01367693:final:Dissolved%20Oxygen&temporalFilter=om%3AphenomenonTime%2C2011-07-13T13:32:51.000Z

returning (abbreviated)

<gml:identifier codeSpace="http://www.opengis.net/def/nil/OGC/0/unknown">o4</gml:identifier>

3. I try the DeleteObservation query:

http://ec2-35-166-3-66.us-west-2.compute.amazonaws.com:8080/52n-sos-webapp/service?service=SOS&version=2.0.0&request=DeleteObservation&observation=o4

and get

Status 500 -

type Exception report

message

description The server encountered an internal error that prevented it from fulfilling this request.

exception

java.lang.NullPointerException
        org.n52.sos.ds.hibernate.dao.series.AbstractSeriesDAO.updateSeriesAfterObservationDeletion(AbstractSeriesDAO.java:426)
        org.n52.sos.ext.deleteobservation.DeleteObservationDAO.checkSeriesForFirstLatest(DeleteObservationDAO.java:137)
        org.n52.sos.ext.deleteobservation.DeleteObservationDAO.deleteObservation(DeleteObservationDAO.java:91)
        org.n52.sos.ext.deleteobservation.DeleteObservationRequestOperator.receive(DeleteObservationRequestOperator.java:62)
        org.n52.sos.ext.deleteobservation.DeleteObservationRequestOperator.receive(DeleteObservationRequestOperator.java:50)
        org.n52.sos.request.operator.AbstractRequestOperator.receiveRequest(AbstractRequestOperator.java:166)
        org.n52.sos.request.operator.AbstractTransactionalRequestOperator.receiveRequest(AbstractTransactionalRequestOperator.java:68)
        org.n52.sos.service.operator.AbstractServiceOperator.receiveRequest(AbstractServiceOperator.java:61)
        org.n52.sos.binding.KvpBinding.doGetOperation(KvpBinding.java:99)
        org.n52.sos.service.SosService.doGet(SosService.java:125)
        javax.servlet.http.HttpServlet.service(HttpServlet.java:624)
        org.n52.sos.service.ConfiguratedHttpServlet.service(ConfiguratedHttpServlet.java:53)
        javax.servlet.http.HttpServlet.service(HttpServlet.java:731)
        org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
        org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:186)
        org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
        org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:343)
        org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:260)
        org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:88)
        org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
        com.thetransactioncompany.cors.CORSFilter.doFilter(CORSFilter.java:168)
        com.thetransactioncompany.cors.CORSFilter.doFilter(CORSFilter.java:233)

As I was typing this in it struck me that my test case had only one observation for the offering, so I was asking to delete the last/only point in the time series. I used InsertResult to add two more observations, and was able to apply DeleteObservation successfully until I tried to delete the last observation. Perhaps there's an edge case here not fully addressed?

I am able to work around this behavior by directly accessing the database, so repair is not urgent.