On Sat, 1 Sep 2018 at 19:56, Nyall Dawson wrote:
> 2. I think there may be a real issue here - I've got at least one
> customer who is having WFS issues with 3.2 and master. BUT: on the
> other hand Travis has always been flaky with any test which uses
> threads, regardless of which area of code
Hi
> On 03 Sep 2018, at 22:54, Jonathan Moules
> wrote:
>
> I'd suggest based on Tom's post that the work should include some sort of
> reliable way of testing the WFS client (and of course full test coverage) - I
> don't know if GeoServer is Docker-happy these days
>
Kartoza publishes
Hi,
I just checked the goals of the work on the WFS provider. It is not a
refactor in fat, sorry for having used that word. The work consists in
having a closer look to the WFS and snapping cache interactions because
they cause lots of problems when the distant database has triggers that
would
On Tue, Sep 4, 2018 at 8:51 AM Jonathan Moules
wrote:
> I'd suggest based on Tom's post that the work should include some sort of
> reliable way of testing the WFS client (and of course full test coverage) -
> I don't know if GeoServer is Docker-happy these days, but the default
> install in a
I'd suggest based on Tom's post that the work should include some sort
of reliable way of testing the WFS client (and of course full test
coverage) - I don't know if GeoServer is Docker-happy these days, but
the default install in a VM should be sufficient for the task (it comes
with test
On Tue, 4 Sep 2018 at 05:50, Even Rouault wrote:
>
> Régis,
>
> Not that I'm against improvements, all the contrary, but just wanted to
> underline that the provider was seriously refactored already in 2.16. Clearly
> the lack of WFS-T support for 1.1 and 2.0 in the scope of those enhancements
>
I agree WFS 3.0 is a much better implementation and it would be great if a
implementation is started soon to track the current standards development.
However, we still have (and will have for a long time) a user need to
support WFS 1.0 and 2.0 - so this still needs to be deal with.
On Tue, Sep 4,
What about starting with/focusing on WFS 3? The new version is really
cleaner and seems much more efficient.
The current WFS implementation in QGIS is much better than previous
versions, even if sometimes making a virtual OGR file il the only way to
use some services. There are really bad server
Can I also add that the refactoring that was funded in 2.16 added tests,
paging support, filter query builder and dynamic caching. There is now a
lot of complexity in the driver due to the complexity of WFS server
implementations and the standard, plus the multi-threading code. If a
refactor is
Hi Even, thanks for pointing that, I missed that history.
I'll ask the dev's for the detailed improvements planned, I dont' have any
detail currently (sorry for that)
Régis
Le lun. 3 sept. 2018 à 21:29, Even Rouault a
écrit :
> Régis,
>
> Not that I'm against improvements, all the contrary, but
Régis,
Not that I'm against improvements, all the contrary, but just wanted to
underline that the provider was seriously refactored already in 2.16. Clearly
the lack of WFS-T support for 1.1 and 2.0 in the scope of those enhancements
can be a source of confusion currently for users. What do
Hi all,
I very much think that the WFS client is an really bad state, and is not
really reliable, especially in WFS-T context.
The good news is that we just have been funded to refactor it !
The work should start in september and land in 3.6. I will let our dev's
come here with more technical
I can't offer any helpful suggestions, but just to let you know I finally had
to disable all my plugin WFS tests. I used to cope, by rerunning failed
Travis runs, but by about three months ago, it seemed no longer usable -
failure after failure.
I was using a third-party WFS, and perhaps I could
Can these failures be reproduced locally if one repeatedly tests those
cases?
On Mon, Sep 3, 2018, 07:02 Nyall Dawson wrote:
> On Sat, 1 Sep 2018 at 20:37, Richard Duivenvoorde
> wrote:
>
> > And myself I also have the feeling that WFS is less stable
>
> This is my experience too, which is why
On Sat, 1 Sep 2018 at 20:37, Richard Duivenvoorde wrote:
> And myself I also have the feeling that WFS is less stable
This is my experience too, which is why I'm not going to 100%
attribute these errors to Travis!
Nyall
> /usable then
> in 2.18 (I release a list of national WFS/WMS/WCS's in
On 09/01/2018 12:43 PM, Alessandro Pasotti wrote:
> Richard, please let's focus on Travis in this thread.
>
> WFS UX issues on 3.x are a complete different topic.
Ok, sorry. What I just wanted to add: it looks like that 'default'-wfs
behaviour has changed, raising wfs problems .
I just wanted
On Sat, Sep 1, 2018 at 12:37 PM Richard Duivenvoorde
wrote:
> On 09/01/2018 11:56 AM, Nyall Dawson wrote:
> > Hi devs,
> >
> > Just raising the question of what we should do about the constant WFS
> > test failures we get on Travis. I'd estimate 1 in 3 builds fails
> > because of WFS related
On 09/01/2018 11:56 AM, Nyall Dawson wrote:
> Hi devs,
>
> Just raising the question of what we should do about the constant WFS
> test failures we get on Travis. I'd estimate 1 in 3 builds fails
> because of WFS related tests hanging.
>
> I'm very reluctant to disable all these tests, because:
On Sat, Sep 1, 2018 at 11:56 AM Nyall Dawson wrote:
> Hi devs,
>
> Just raising the question of what we should do about the constant WFS
> test failures we get on Travis. I'd estimate 1 in 3 builds fails
> because of WFS related tests hanging.
>
> I'm very reluctant to disable all these tests,
Hi devs,
Just raising the question of what we should do about the constant WFS
test failures we get on Travis. I'd estimate 1 in 3 builds fails
because of WFS related tests hanging.
I'm very reluctant to disable all these tests, because:
1. WFS is super important.
2. I think there may be a real
20 matches
Mail list logo
