Andre,

The reason I closed it as "not a bug" was because I knew it was done by intentional design (not by me, but by the initial developer of wfs-ng) for a particular purpose and therefore I did not consider it a bug. You do make good points to criticise this choice, which does affect backwards compatibility. I do not personally oppose your alternative suggestion.

Regards
Niels

On 04/22/2016 07:48 PM, Andrea Aime wrote:
On Thu, Apr 21, 2016 at 7:52 PM, Jody Garnett <jody.garn...@gmail.com <mailto:jody.garn...@gmail.com>> wrote:


            > Hum... wfs-ng was supposed to be a drop-in replacement,
            not having a upgrade
            > path seems to be a serious issue to me.
            > Where is it documented?

            Quick search got us this:
            https://osgeo-org.atlassian.net/browse/GEOT-4883
and we googled some more messages on it.
        A backwards incompable change blocking upgrades presented as a
        GeoServer requirement and resolved as "not a bug"...


    Reading this issue, and I agree it is not a bug - the new
    datastore is behaving as designed in order to preserve valid names
    for GML generation.


Jody I believe we have a problem here, in terms of responsibilities. Is it really the job of the stores to decide what is valid, and what is not? Not all usage is WFS cascading, stores are used for a number of other cases, which might have different naming limitations.

Also from a consistency point of view, did you know that you can create a typename like "a:b" using a postgis store?

> create table "a:b" (id serial, geom geometry(POLYGON, 4326));
CREATE TABLE

And then the datastore is happily returning a:b as the typename,
And of course we also have shapefiles, on linux a file name like a:b.shp is also completely valid.

With you and Niels claiming that is not a bug, we have a difficult situation, as nobody else can just jump in and make the upgrade path easier, since according to your evaluation, we'd be introducing a bug... (and from that same point of view,
then jdbc store and shapefile store are buggy too...).

Unless of course your position is a bit more relaxed, as in, you don't consider that a bug, but the behavior returning the native
name is valid too.


    For this specific case the old datastore would of required a
    similar fix (to prevent type names being of the form
    "local_namespace:remote_namespace:typename").

        As far as I know GeoServer was already handling the ":" in the
        name, and the admin is able to rename layers as they see fit.
        Yep, there is code stripping the prefix:
        
https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/catalog/CatalogBuilder.java#L1212


    GeoServer may have work arounds, but I do not mind if the new
    DataStore is taking more care to produce consistent type names.


See Mark's situation though. I'm also aware of other situations like this one that will be broken by an upgrade (systems configured
to work against well known type names in remote servers).

Mind, I checked, GeoServer is not affected, because internally we have this little thing that hides from GeoServer the columns and
guess what, replaces them with underscores. See here:

https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/vfny/geoserver/util/DataStoreUtils.java#L74

and then the retyper does this:

https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/feature/retype/RetypingDataStore.java#L252

So luckily for GeoServer even if the store did change its behavior, nothing changed config wise (we end up seeing a_b as the native type name regardless of whether the store returns a:b or a_b because of the above wrapper).

Given this, I'd still make it possible for GeoTools users to upgrade from wfs to wfs-ng without this much hassle by exposing the
actual native type name.
If the worry is about valid type names for GML, I'm more than happy to contribute a little utility wrapping store based on the GeoServer one that does the same thing as RetypingDataStore, but centralized in one place, and optional, only for those that actually need to do GML encoding.
A DataUtilities.makeGmlCompatible(DataStore) -> DataStore of sorts.

Cheers
Andrea


--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.


-------------------------------------------------------


------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z


_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to