[Geoserver-devel] New cite results for 1.6.5

GeoServer GeoServer Developer
,
1

Hi All,

I ran cite for 1.6.5 and there is actually only one legitimate failure. Before I get into the failure here is what i did:

1. Checked out the versions of the test cases tagged from ows4. Available at:

https://svn.opengeospatial.org:8443/ogc-projects/cite/tags/2007-RC1

2. Patched the LockFeature and GetFeatureWithLock tests. The issue with them as written is that the spec says that when a transaction occurs against a locked feature and the transaction does not specify the proper lock, that the server should either:

a) an exception can be thrown or
b) a unsuccessful transaction should be reported.

GeoServer does a) but the tests only check the b) case. Patching to solve this was simple.

3. Copied wfs/1.1.0 under the url above into the community/cite/tests/wfs/ directory (renaming the regular 1.1.0 directory to avoid conflict)

4. Run the engine as normal.

Now... to the failure. The test that fails is one that is doing a PropertlyIsLike filter with a date literal (nasty yes!!):

    <wfs:GetFeature>
          <wfs:Query srsName="urn:x-ogc:def:crs:EPSG:6.11.2:4326" typeName="sf:PrimitiveGeoFeature">
             <ogc:Filter>
                <ogc:PropertyIsLike escapeChar="\" singleChar="?" wildCard="*">
                   <ogc:PropertyName>sf:dateProperty</ogc:PropertyName>
                   <ogc:Literal>20*-10-??</ogc:Literal>
                </ogc:PropertyIsLike>
             </ogc:Filter>
          </wfs:Query>
       </wfs:GetFeature>

This test has actually been an issue for quite some time with postgis. Before it merely did not return any records, but now it seems to bomb out (on my version of postgres it does anyways).

When I looked into this issue before it was not trivial to fix. And actually i could not really think of a solution that was not a total hack. And since for ows5 we used h2 for cite tests (which does not suffer the same issue due to the string representation of dates) i did not fix it.

So regardless of the reasons the question is do we release without being cite compliant. Its a tough call because this is really a small corner case if you ask me... but we always set the bar for passing all of cite when making releases. Although we have not passed this test for some time so it seems we have been... not sure.

What do others think?

-Justin

--
Justin Deoliveira
Software Engineer, OpenGeo
http://opengeo.org

2

Justin Deoliveira ha scritto:

Hi All,

I ran cite for 1.6.5 and there is actually only one legitimate failure. Before I get into the failure here is what i did:

1. Checked out the versions of the test cases tagged from ows4. Available at:

https://svn.opengeospatial.org:8443/ogc-projects/cite/tags/2007-RC1

This unfortunately requires a valid login.

<snip>

Now... to the failure. The test that fails is one that is doing a PropertlyIsLike filter with a date literal (nasty yes!!):

    <wfs:GetFeature>
          <wfs:Query srsName="urn:x-ogc:def:crs:EPSG:6.11.2:4326" typeName="sf:PrimitiveGeoFeature">
             <ogc:Filter>
                <ogc:PropertyIsLike escapeChar="\" singleChar="?" wildCard="*">
                   <ogc:PropertyName>sf:dateProperty</ogc:PropertyName>
                   <ogc:Literal>20*-10-??</ogc:Literal>
                </ogc:PropertyIsLike>
             </ogc:Filter>
          </wfs:Query>
       </wfs:GetFeature>

This test has actually been an issue for quite some time with postgis. Before it merely did not return any records, but now it seems to bomb out (on my version of postgres it does anyways).

Aaah, yeah, I remember that test, it breaks only with recent versions of
Postgres, with my 8.1 it does not. In fact I opened a jira issue and
suggested a fix as well few months ago:
http://jira.codehaus.org/browse/GEOS-1854

Then it fell out of the radar and completely forgot about it. So it
seems the fix would be to make the postgis sql encoder force the
attribute to varchar when encoding like filters. Shall I give it
a shot?

Btw, this should really be added to the JDBCDataStore test suite in
a JDBCDateTimeTest class, since it's in fact a nasty one :slight_smile:

Cheers
Andrea