[CITE-Forum] WFS 2.0 Conformance Test Suite Locking WFS test cases

Richard Martell rmartell at galdosinc.com
Tue Jul 15 14:04:40 EDT 2014


Julien,

I committed fixes for these issues (master branch).

-- Richard


From: Julien Charon [mailto:Julien.Charon at avitech.aero]
Sent: Monday, 14 July, 2014 23:01
To: Richard Martell; cite-forum at lists.opengeospatial.org
Cc: Michele Laghi
Subject: AW: [CITE-Forum] WFS 2.0 Conformance Test Suite Locking WFS test cases

  Hi Richard,


Thank you very much for your feedback and for opening the bug reports. Regarding issue 3 you are right, I didn't look at the code deep enough, sorry.


Mit freundlichen Grüßen / With kind regards,

Julien Charon

Avitech GmbH
Engineering AxL
Tel.: +49 (0)7541/282-177
Fax: +49 (0)7541/282-199
e-mail: julien.charon at avitech.aero<mailto:julien.charon at avitech.aero>
________________________________________________
Avitech GmbH
Principal Office: Bahnhofplatz 1 | 88045 Friedrichshafen | Germany
Court Registration: Amtsgericht Ulm | HRB 728293
Geschäftsführer/Managing Director: Antonio Maria Gonzalez Gorostiza
http://avitech.aero<http://avitech.aero/>

This message may contain confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system.

Von: Richard Martell [mailto:rmartell at galdosinc.com]
Gesendet: Montag, 14. Juli 2014 22:15
An: Julien Charon; cite-forum at lists.opengeospatial.org<mailto:cite-forum at lists.opengeospatial.org>
Cc: Michele Laghi
Betreff: RE: [CITE-Forum] WFS 2.0 Conformance Test Suite Locking WFS test cases

Julien,

Regarding issue 3, the second GetFeatureWithLockRequest is a composite query:

Q1: Lock ALL instances of Type1
Q2: Lock SOME of Q1 plus all instances of Type2 (the second query is appended to the original request)

The Q2 results must omit instances already locked by Q1. I agree that this test can be revised to operate on only one feature type:
<https://github.com/opengeospatial/ets-wfs20/issues/3?

Please feel free to comment on any of these.

-- Richard



From: CITE-Forum [mailto:cite-forum-bounces at lists.opengeospatial.org] On Behalf Of Richard Martell
Sent: Monday, 14 July, 2014 12:04
To: Julien Charon; cite-forum at lists.opengeospatial.org<mailto:cite-forum at lists.opengeospatial.org>
Cc: Michele Laghi
Subject: Re: [CITE-Forum] WFS 2.0 Conformance Test Suite Locking WFS test cases

Hi Julien,

Here are some responses to the first two issues you raised. The last one (#3) will require a closer review of the GetFeatureWithLockTests#lockSomeQueryResults test method.

1a. I opened a GitHub bug report for this: <https://github.com/opengeospatial/ets-wfs20/issues/1>

1b. Another bug report: <https://github.com/opengeospatial/ets-wfs20/issues/2>

2. I'll fix the expected status code per 1b. The WFS2 spec doesn't distinguish expired from non-existent lock identifiers in LockFeature requests (12.2.4.2). The "InvalidLockId" exception code is restricted to Transaction requests. Perhaps you might consider submitting a CR.

<http://www.opengeospatial.org/standards/cr>


-- Richard


From: CITE-Forum [mailto:cite-forum-bounces+rmartell=galdosinc.com at lists.opengeospatial.org] On Behalf Of Julien Charon
Sent: Thursday, 10 July, 2014 01:55
To: cite-forum at lists.opengeospatial.org<mailto:cite-forum at lists.opengeospatial.org>
Cc: Michele Laghi
Subject: [CITE-Forum] WFS 2.0 Conformance Test Suite Locking WFS test cases

  Hi everyone,


I have some questions and comments concerning the Locking WFS test cases of the WFS 2.0 Conformance Test Suite (Version r16). I refer to the single test cases by their names as listed in the HTML reports  that are generated after a test run:


1.       lockAllQueryResults_20Seconds():

a.       The stored query "urn:ogc:def:query:OGC-WFS::GetFeatureByType" is assumed to exist and used in the request. However, this stored query isn't defined in the WFS 2.0 specification. It would be nice if it was defined there. On the other hand that request could be expressed using an ad hoc query with the typeNames attribute.

b.      The test case expects an exception report with the exception code "LockHasExpired" and the HTTP status code 400. However, the specification defines the HTTP status code 403 for this exception code (Table D.2).  Is this a mistake in the specification?

2.       resetNonexistentLock(): as in point 1.b above, the exception code "LockHasExpired" and HTTP status code 400 are expected, so there's the same problem here. I also wondered if exception code "InvalidLockId" wouldn't be more suitable for this test case, as the lock id actually doesn't exist so it can not have expired.

3.       lockSomeQueryResults(): according to the comment in the source code of the test case, it is expected to do the following:
"Submits a request to lock all instances of a randomly selected feature type (Q1) for 60 seconds. Another request is then submitted to lock SOME of Q1 plus the members of result set Q2 (different feature type). This request should succeed; the response shall only contain those features that were successfully locked (members of Q2 results but <strong>not</strong> Q1 results that were previously locked)"
However, having a look at the code I noticed a few things that I'd like to point at:

a.       This test case is the only one in the whole test suite that expects instances of more than one feature type to exist and it fails if there are only instances for a single feature type. In my opinion, the behaviour could also be tested by locking some instances of a feature type, e.g. by id. The second request would then call GetFeatureWithLock for the whole feature type and the test case would succeed if the feature instances locked in the first step were not present in the response to the second request.

b.      The feature type Q2 is determined by picking randomly a feature type out of the list of available feature types. So, as mentioned above, this will always return the same feature type for a WFS that only provides instances for a single feature type. But even if that is not the case, and a  WFS provides instances for more than one feature type, the test can only succeed by chance. But the most important thing regarding the test case is that it will fail or succeed by chance between different test runs, so it is not deterministic. There is even a comment in the code (WARNING: could be same feature type) describing that problem, but in my opinion it would be better to check if Q1 is the same as Q2 before sending the second request.

c.       Sticking to the comment describing the test case, I expected the second request trying to lock features of type Q1 as well as of type Q2. However, in the code it seems like only the feature type Q2 is set for the second request. So even if there are instances for more than one feature type, the second request will never try to get locks for more than one feature type.

Thank you for you support and please don't hesitate to ask me questions if something is unclear.


With kind regards,

Julien Charon

Avitech GmbH
Engineering AxL
Tel.: +49 (0)7541/282-177
Fax: +49 (0)7541/282-199
e-mail: julien.charon at avitech.aero<mailto:julien.charon at avitech.aero>
________________________________________________
Avitech GmbH
Principal Office: Bahnhofplatz 1 | 88045 Friedrichshafen | Germany
Court Registration: Amtsgericht Ulm | HRB 728293
Geschäftsführer/Managing Director: Antonio Maria Gonzalez Gorostiza
http://avitech.aero<http://avitech.aero/>

This message may contain confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system.



________________________________
Avitech GmbH
Principal Office: Bahnhofplatz 1 | 88045 Friedrichshafen | Germany
Court Registration: Amtsgericht Ulm | HRB 728293
Geschäftsführer/Managing Director: Antonio Maria Gonzalez Gorostiza
VAT No.: DE223719716
http://avitech.aero
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/cite-forum/attachments/20140715/ce563ec4/attachment-0001.html>


More information about the CITE-Forum mailing list